#2255 closed defect (fixed)

Experiment with virtualenv based packaging in the petmail style.

Reported by: nejucomo Owned by: daira
Priority: normal Milestone: 1.11.0
Component: packaging Version: 1.10.0
Keywords: virtualenv pip setuptools install build packaging Cc: warner
Launchpad Bug:


Change History (9)

comment:1 Changed at 2014-07-02T03:15:03Z by 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.
Last edited at 2015-06-07T10:32:06Z by daira (previous) (diff)

comment:2 Changed at 2014-07-02T03:29:24Z by nejucomo

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

comment:3 Changed at 2014-07-02T03:34:04Z by 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.

comment:4 Changed at 2014-07-24T01:17:14Z by 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 requirements.txt files for each platform, containing 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?

Last edited at 2014-07-24T01:18:04Z by daira (previous) (diff)

comment:5 Changed at 2014-07-29T21:00:02Z by daira

  • Component changed from unknown to packaging
  • Keywords virtualenv pip setuptools install build packaging added
  • Milestone changed from undecided to 1.12.0
  • Status changed from new to assigned

comment:6 Changed at 2014-08-19T17:47:06Z by daira

See also #2077 (pip packaging plan).

comment:7 Changed at 2014-09-23T23:30:30Z by warner

  • Cc warner added

comment:8 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:9 Changed at 2016-03-26T23:14:58Z by warner

  • Milestone changed from 1.13.0 to 1.11.0
  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.