Skip Montanaro <s...@pobox.com> writes: > Hmmm... And my git repo?
You are keeping your virtualenv separate from your working tree, right? I put mine in ‘/var/local/devel/$USER/virtualenvs/foobar/’ where “foobar” is the specific virtualenv name. This allows an arbitrary number of virtualenvs separate for each user (‘/var/local/devel/$USER/’ is owned by each $USER), but all under one directory tree where they can be treated specially for backup, cleanup, permissions, or whatever. > I imagine I will eventually figure this out, but updating an existing > virtualenv in place to adapt to a new version of Python (say, a new > micro) or some of its libraries (contents of requirements.txt) seems > like it would be a very nice thing to have. Yes, you simply ‘pip install -r ./requirements.txt’ again. It does a simplistic “is the package already installed at this version in the currently-active virtualenv? If not, install it in that virtualenv”. The environment variables that determine where the virtualenv lives are managed by ‘/var/local/devel/$USER/virtualenvs/foobar/bin/activate’. You don't have the packages cluttering up your working tree. -- \ “I don't know anything about music. In my line you don't have | `\ to.” —Elvis Aaron Presley (1935–1977) | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
