[Distutils] eggs and PYTHONPATH (cont'd from peak list...)

[Michael Bayer]

Hi  -

I have some further thoughts on the PYTHONPATH topic Phillip and I  
were discussing on the PEAK list a few days ago.

On Jun 28, 2006, at 4:09 PM, Phillip J. Eby wrote:
> Eggs always override non-eggs, because eggs can be controlled in  
> ways that non-egg paths can't.  The order is (roughly):
>
> eggs on PYTHONPATH
> eggs in site-packages
> non-eggs on PYTHONPATH
> non-eggs in site-packages
>

I would propose the order be this:

eggs on PYTHONPATH
non-eggs on PYTHONPATH
eggs in site-packages
non-eggs in site-packages

It is possible that a non-egg install might be named in PYTHONPATH  
for a package for which newer versions that are setuptools/egg- 
enabled are installed system-wide.  However, I cant think of a  
possible scenario where a path would explicitly exist in PYTHONPATH,  
non-egg or egg, where the user would still like the system-wide  
installation to take precedence, regardless of versioning or anything  
else.  Otherwise why put the path on PYTHONPATH ?  (Though Im  
guessing there is such a scenario, id just like to see what it is).    
I know that eggs are more powerful than non-egg paths, allowing  
precedence to take place based on versioning, which is obviously  
extremely useful; but I think the idea of PYTHONPATH is that system- 
wide library paths can be explicitly overridden regardless of any  
versioning logic taking place either within site-packages or elsewhere.

For example, if a particular package on a multi-user shell account is  
upgraded systemwide from its previously non-egg version to a  
setuptools/egg version, then any users who have applications running  
on a custom PYTHONPATH setup with dependencies on their locally- 
installed, non-egg versions will now have a broken install; theyd  
have to log in, read all the setuptools docs to figure out whats  
going on, and do the "virtual python" setup in order to fix things.

It seems that setuptools redefines the intention of PYTHONPATH from  
being a "runtime path determination" variable to an "installation  
path determination" variable;  why repurpose PYTHONPATH in this way,  
especially when many packages are going to exist in egg/non-egg  
formats?  why not use another variable such as SETUPTOOLSPATH ?

Im sure theres other reasons im missing for why its the way it is, so  
I apologize for harping on this.  Also was wondering if anyone else  
had this same question.

- mike