ianb at colorstudy.com
Sat Mar 11 22:22:28 CET 2006
I wrote a script last night that implements some of the ideas of a
working environment, similar in goals to virtual-python.py, but it
doesn't actually work like that.
When you run "python working-env.py env" you get:
activate (something you source in your shell to activate this
You activate the environment by adding env/lib/python2.4 to your
PYTHONPATH, and maybe adding env/bin/ to your PATH.
The custom site.py accomplishes most of the work, I guess. It's just
like the normal site.py, except it doesn't add site-packages (I should
probably make an option so you can set it up either way).
distutils/__init__.py is Ronald Oussoren's suggestion for monkeypatching
distutils. It both manages to get the working environment's
distutils.cfg to be used (comes for free, since distutils.dist looks
alongside distutils.__file__), and it substitutes __WORKING__ for the
actual working directory.
The setuptools monkeypatch changes how scripts are generated. But I
don't like how it works. It changes scripts to look more like:
import sys, os
join, dirname = os.path.join, os.path.dirname
lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' %
... normal stuff ...
Monkeypatching distutils is fine, because it's not going anywhere, but
monkeypatching setuptools is not going to be so reliable. But I guess
we just need to figure out exactly what we want to do, then move those
changes to setuptools. Also, distutils should probably be monkeypatched
directly in some fashion, so that distutils install also installs
scripts with this header.
A goal I have -- that is pretty much accomplished so far -- is that the
working environment be movable, and all paths be relative. But
setuptools creates some absolute directory names in .pth files, I believe.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Distutils-SIG