Opened at 2013-04-22T22:23:23Z
Last modified at 2020-01-17T14:28:08Z
#1951 closed defect
"one-file" executable for non-developers — at Version 2
| Reported by: | warner | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | undecided |
| Component: | packaging | Version: | 1.9.2 |
| Keywords: | bbfreeze packaging install build | Cc: | |
| Launchpad Bug: |
Description (last modified by zooko)
I'd like it if Tahoe users (not developers) could download a single file and run it, rather than pointing them at "quickstart" instructions that begin with a source download/checkout and then some build steps. And I'd love it if this meant we could reduce complexity (by reducing functionality) of our setup.py, because we'd no longer need to support a single simple command to acquire/build/locally-install dependencies.
For the one-file executable, I'm thinking bbfreeze, about or if that doesn't work then something homemade. I recently learned that you can concatenate a #!/usr/bin/env python line with a zipfile that contains a directory with an __init__.py inside it, and running the result will cause python to execute that __init__.py. This sounds like a better-supported version of what bbfreeze does (or maybe this is what bbfreeze uses these days, I dunno). We'd probably publish one version for linux, and a different one for windows. Maybe one per platform if their binary dependencies are different. I'd want each one to be self-contained: no dependency upon system-supplied libraries.
For the remaining setup.py, I'm thinking that maybe virtualenvs are the way to go. Developer instructions could look like:
- create and activate a virtualenv somewhere
- run python setup.py develop from the tahoe source tree, which will get python from the virtualenv, which will read requirements.txt and install everything therein to the virtualenv, then will pseudo-symlink tahoe itself into the virtualenv
- run ./bin/tahoe, which has a #!/usr/bin/env python, and will thus use the virtualenv's python. Or, use the virtualenv's bin/tahoe.
I believe packagers usually build OS packages by running python setup.py install in a fakeroot environment, possibly with additional options to install the results into a local directory instead of /usr. And that they expect this install to not drag in any dependencies. So I'd like that to work for packagers.
I don't know how long-term installation should work, but I'd like some variant on sudo python setup.py install to work, maybe in the form of two separate commands (one to install dependencies, the second to install tahoe itself). Another option is to have developer/installers construct their virtualenv as above, then simply symlink the virtualenv's bin/tahoe into /usr/local/bin or something.
I think it's ok to require that developers get virtualenv and whatever it requires (pip, setuptools, etc) installed first, and that we shouldn't feel obligated to provide additional source code to install those for them.
https://pypi.python.org/pypi/bbfreeze/ is the recently-updated bbfreeze package, which apparently knows how to copy system-supplied shared libraries and DLLs into the generated executable.