[Python-Dev] [Distutils-SIG] PYTHONPATH installation (was Re: PEP 365 (Adding the pkg_resources module))

[Phillip J. Eby]

At 10:18 PM 3/19/2008 -0600, zooko wrote:
>The fact that easy_install creates a site.py that changes the
>semantics of PYTHONPATH is probably the most widely and deservedly
>hated example of this kind of thing [2].

Yep, this was an unfortunate side effect of eggs growing outside 
their original ecological niche.  Without the 'site' hack, it was 
impossible to install eggs to user directories and avoid installation 
conflicts.

Specifically, if someone installed a package to PYTHONPATH with the 
distutils, and then installed a later version using setuptools, the 
setuptools-installed version would always end up on sys.path *after* 
the distutils-installed version.  Detecting this condition and 
handling it properly was a major problem for users of easy_install, 
who wanted it to "just work".

Standardization of a PEP 262-style installation database is still 
needed to address these problems, not to mention 
uninstallation.  Maybe now with some package manager folks paying 
some attention here, we can do something about that.


>[2] http://www.rittau.org/blog/20070726-02
>    And no, PJE's suggested "trivial fix" does not satisfy the
>objectors, as it can't support the use case of "cd somepkg ; python 
>./ setup.py install ; cd .. ; python -c 'import somepkg'".

Well, it replaces the hack being complained about, with the problem 
that the hack was introduced to fix.  :)

Again, to properly fix this, we need a metadata standard for who owns 
what packages -- and it should probably include information about the 
*tool* that did the installation, so that system packagers can either 
tell Python-level tools to keep their hands off, or tell Python how 
to run the tool in question.