[Distutils] Working environment

Iwan Vosloo iv at lantic.net
Wed Mar 8 08:15:12 CET 2006

Ian Bicking <ianb at colorstudy.com> writes:

> Another option is a completely new python interpreter bound to the 
> environment.  Basically the virtual-python.py option 
> (http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-python). 
>   In this model using env/bin/python indicate the proper environment, 
> and you'd have local installs of *everything* including easy_install. 
> This fixes so many problems without crazy hacks that it strongly appeals 
> to me, especially if we can make it somewhat lighter.  I get this 
> /usr/lib/python2.4.zip on my path, that doesn't usually exist (does it 
> ever get created by default); if we could create that somehow on demand 
> and use such a big-bundle-zip, that seems lighter and faster and nicer. 
>   If we just put .pyc files in it, and those .pyc files refer back to 
> the actual module source (in /usr/lib/python2.4/), then tracebacks 
> should also still work, right?  No actual symlinks either, so it should 
> work on Windows.  I'm not entirely sure where I'm going with this, though.

Just a thought... This sounds like a clean approach and powerful.
What if, for example, you work on a machine with python 2.4 installed,
but you want an environment with python 2.5?  With what you're
proposing here you could go totally heavyweight and have the whole
python distribution installed in your working invironment only.

Or distro's could have a python-dev type package which installs in a
location other than their official python installation, so that you
can still do your more lightweight thing.  Reminds me of a database
'installation' with seperate 'instances' of it on the same machine,
each with its own data.

I'm actually thinking that this is useful especially in the case where
you're working on a distribution which is tightly bound to an older
version of python - but you want to develop on a newer version.


More information about the Distutils-SIG mailing list