Add a setup.py, and upload vagrant-spk to PyPI

[zenhack]

This would let folks just do pip install vagrant-spk (maybe with --user to do it account-wide instead of user-wide) rather than having to check out the git repo.

If we decide to keep the enter_grain helper, we could publish a wheel that includes it, which would avoid having to commit it to the repo (see #253) without forcing everyone to set up a rust toolchain just to start developing apps.

[zenhack]

This would also let us refactor vagrant-spk into more than one file, which would be nice.

[ocdtrekkie]

Would we need to combine building enter-grain with the build process for the Windows installer? My assumption is at bare minimum we would need to add building enter_grain to the release.sh flow. (Definitely still will be simpler if we just kill it and not have to worry about a separate binary.)

I personally am kinda fond of the single-script format of vagrant-spk, I feel like it's easier for me to wrap my head around it and track where things are coming from and going to with a Ctrl-F.

Biggest perk to a pip install is probably that #157 potentially becomes incredibly trivial.

[paulproteus]

PyPI is cool, and I use it nearly every day. Having said that, I find that when there are developer tools published on PyPI, it's not usually a great fit for me, unless they help me with Python development in particular. The last time I checked, pip install-ing something doesn't reliably add it to one's $PATH, so it can create lots of confusion. By contrast, adding vagrant-spk to Homebrew's repo would ensure it ends up on at least macOS users's paths. @ocdtrekkie , do you use something like nuget or Chocolatey?

@zenhack , I'd like to hear more about the underlying need.

I agree that #157 is made easier by having a PyPI package. I added a comment on #157 advising another approach that doesn't relate to PyPI, in case you end up not going with the PyPI direction.

Unrelated-ish list of some slightly relevant tools.

• flit is basically a setup.py alternative. You might enjoy it if you publish to PyPI. https://github.com/takluyver/flit . It decreases boilerplate.

• PyOxidizer is a way to turn a Python module into a single-file binary, and it seems to be well-maintained. I'd consider that approach if I were starting from scratch. See also https://pyoxidizer.readthedocs.io/en/latest/packaging.html#creating-a-pyoxidizer-project

• pipx is a program which helps ensure that pip users have their $PATH set up properly, and other conveniences. See: https://github.com/pipxproject/pipx & https://github.com/pipxproject/pipx#walkthrough-installing-a-package-and-its-applications-with-pipx . If you go the PyPI route, you might advise non-Python-aware users to run the following.

brew install pipx
pipx ensurepath
pipx install vagrant-spk
vagrant-spk --help

Feel free to not reply to the questions in this comment. Those are just my thoughts upon reading this issue. Cheers!

[ocdtrekkie]

@paulproteus I've used NuGet when adding dependencies to a Visual Basic or C# project. But never to install software on my computer in the sense that I would think about such things. I've heard of Chocolately but never used it personally. (At work I use a little bit fancier software deployment tool, of course.)

[ocdtrekkie]

I am personally not big on package managers. Possibly because there are too many and they introduce a new point of failure and place bitrot occurs.

If we want to get binaries out of the repo, shouldn't we "just" build them for the releases tab and have people download and unpack from there instead of cloning the repo? Or we could host them where Sandstorm releases are hosted if we want to self-host as much as possible, and have an install script similar to Sandstorm's own.

EDIT: Add quotes around "just" for @paulproteus.

[zenhack]

Re: stuff not ending up users' PATH, the README already tells users they need to adjust PATH to add vagrant-spk, so that's not a regression; we can just ask them to add ~/.local/bin instead.

I think proper setup.py packaging would be a boon for maintainability in a number of ways, but "just" building the binary and asking folks to download a release tarball seems reasonable to me as a next step regardless.