Mercurial > hg > carton
changeset 31:8fef97a25925
near version bump and documentation
author | Jeff Hammel <jhammel@mozilla.com> |
---|---|
date | Mon, 11 Jul 2011 12:56:46 -0700 |
parents | 0b9c124f128b |
children | 00ca88ef1c33 |
files | README.txt carton.py setup.py |
diffstat | 3 files changed, 57 insertions(+), 4 deletions(-) [+] |
line wrap: on
line diff
--- a/README.txt Mon Jul 11 11:01:48 2011 -0700 +++ b/README.txt Mon Jul 11 12:56:46 2011 -0700 @@ -1,1 +1,54 @@ -See the docstring of carton.py for documentation +carton +====== + +make a self-extracting virtualenv from directories or URLs of packages + +See the docstring of carton.py for documentation: http://k0s.org/mozilla/hg/carton/file/tip/carton.py#l3 + +Carton provides a one-file portable package of a virtualenv and all of +its software. + + +Why did you write this thing? +----------------------------- + +For whatever reasons, people have trouble using virtualenv so I +figured I'd make that easy. People also seem to believe that you can +zip up a virtualenv and treat it as portable. In general, virtualenvs +are architecture and library dependent, so this isn't a good idea. +carton works around this problem by packaging the instructions +necessary to make the virtualenv instead of dealing with +library/hardware incompatabilities. + + +Should I use carton for my deployment strategy? +----------------------------------------------- + +Maybe. Carton is pretty minimalist. It does effectively one thing: +makes a file that unfolds to a virtualenv with software setup for +development. If this fits in with what you want to do, then sure! If +not, then probably not. + + +TODO +---- + +carton is essentially finished. Features can be added by request +(just mail me: jhammel __at__ mozilla __dot__ com), but the scope of +the project is pretty much fulfilled. + +There are a few items I would like to add: + +- currently, carton only works if connected to a network or if a local + virtualenv tarball is specified with `--virtualenv`. I would like to + make a script, `regen_virtualenv.py`, that would add a hashed value + of the virtualenv tarball to the global `VIRTUAL_ENV` + variable. Similarly, one should be able to retrieve the stripped + down version of the script without this hash if desired + +- ... and being able to take virtualenv from its import path, if + available + +- it would be nice to be able to specify a post-deployment script to + be run +