Experiment with virtualenv based packaging in the petmail style.

[nejucomo]

Some notes on how nejucomo generated ./requirements.txt:

1. Edited ./setup.py to rename support to legacysupport.
2. renamed support to legacysupport in .gitignore.
3. recursively copied ./support from petmail
4. spliced in the SafeDevelop and run_command from petmail, but renamed the latter to avoid a collision from default tahoe setup.py.
5. Ran python ./setup.py safe_develop mainly to initialize ./venv (but perhaps it would be simpler to run python ./support/virtualenv.py ./venv)
6. Ran ./venv/bin/pip install . to use the existing ./setup.* to install dependencies into the new ./venv.
7. Generated requirements.txt using the existing ./venv by running ./venv/bin/python ./venv/bin/peep.py freeze > ./requirements.txt
8. manually removed wsgiref and allmydata-tahoe from requirements.txt
9. deactivated ./venv then ran python ./setup.py safe_develop to trigger peep's display of package hashes.
10. overwrote requirements.txt with the output of peep.

[nejucomo]

I've just pushed an implementation of the above steps to ​https://github.com/nejucomo/tahoe-lafs/commits/2255-virtualenv-packaging.messy

[nejucomo]

Warner has an independent implementation of this approach which was created in "parallel sprint race mode": ​https://github.com/warner/tahoe-lafs/tree/venv

That implementation was more liberal in hacking out most of ./setup.py.

[daira]

So, I see how this works for source packages, or if the requirements.txt is created on the same platform as the build in the virtualenv. I don't see how it works for binary eggs -- wouldn't we need to ship different requitements.txt files for each platform, with different hashes?

Perhaps it is sufficient to have a requirements.txt for Windows 32-bit w/ Python 2.7, one for Windows 64-bit w/ Python 2.7, and one for every other platform that assumes a compiler and builds everything from source?

[daira]

See also #2077 (pip packaging plan).

[warner]

Milestone renamed

[warner]

We've switched to virtualenv-based installation. Not quite in the style that Nathan and I were exploring (where a new command creates+populates a virtualenv for you), but I think the existing #2055 build-it-safely ticket can cover the distance between what we've got now (virtualenv; pip install) and a peep/requirements.txt -based safe-build step on top of it. So I think we can close this one out.