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