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. http://svn.colorstudy.com/home/ianb/working-env.py When you run "python working-env.py env" you get: env/ bin/ activate (something you source in your shell to activate this environment) conf/ src/ lib/python2.4/ distutils/__init__.py distutils/distutils.cfg setuptools/__init__.py setuptools.pth site.py 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: #!/usr/bin/python -S import sys, os join, dirname = os.path.join, os.path.dirname lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % tuple(sys.version_info[:2])) sys.path.insert(0, lib_dir) import site ... 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@colorstudy.com | http://blog.ianbicking.org
At 03:22 PM 3/11/2006 -0600, Ian Bicking wrote:
#!/usr/bin/python -S import sys, os join, dirname = os.path.join, os.path.dirname lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % tuple(sys.version_info[:2])) sys.path.insert(0, lib_dir) import site ... normal stuff ...
FYI, I plan to write a proposal next week for script path freezing, along the lines of what I talked with you and Jim Fulton at PyCon about. The basic idea is that there'll be a '.pylibs' file alongside the script (e.g. 'foo.pylibs' alongside a 'foo' script) that lists what should be at the front of sys.path. There are still some details to be worked out, but the basic idea is that this would happen in such a way as to ensure that precisely the libraries needed by the script would be first on sys.path, so that it would "inherit" default versions from the environment for plugins or dynamic dependencies only.
Phillip J. Eby wrote:
At 03:22 PM 3/11/2006 -0600, Ian Bicking wrote:
#!/usr/bin/python -S import sys, os join, dirname = os.path.join, os.path.dirname lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % tuple(sys.version_info[:2])) sys.path.insert(0, lib_dir) import site ... normal stuff ...
FYI, I plan to write a proposal next week for script path freezing, along the lines of what I talked with you and Jim Fulton at PyCon about. The basic idea is that there'll be a '.pylibs' file alongside the script (e.g. 'foo.pylibs' alongside a 'foo' script) that lists what should be at the front of sys.path.
Will this happen before the import of site.py? I would very much like it to. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
participants (2)
-
Ian Bicking
-
Phillip J. Eby