[tahoe-lafs-trac-stream] [tahoe-lafs] #1951: "one-file" executable for non-developers

[tahoe-lafs]

#1951: "one-file" executable for non-developers
-----------------------+---------------------------
 Reporter:  warner     |          Owner:
     Type:  defect     |         Status:  new
 Priority:  normal     |      Milestone:  undecided
Component:  packaging  |        Version:  1.9.2
 Keywords:             |  Launchpad Bug:
-----------------------+---------------------------
 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.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1951>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage