[PEAK] installation troubles / how to uninstall setup tools

Phillip J. Eby pje at telecommunity.com
Thu Feb 9 19:57:26 EST 2006


At 06:31 PM 2/9/2006 -0500, Karl Pietrzak wrote:
>After reading http://docs.python.org/lib/module-site.html, I got the
>impression that the site-packages directory is _the_ directory from
>which .pth files are read, and nowhere else.
>
>Is this not true?

If you look at site.py's source, you'll see that many platforms have more 
than one such directory -- even without being locally patched by the distro.


> > I am, however, working on making this a more painless process.  The fact
> > that most Linux distros patch Python in mutually incompatible ways doesn't
> > help much, though.  :(
>
>Could you elaborate on the myriad "mutually incompatible ways" distros patch
>Python?  I'm curiously because I'm in the process of writing an article on
>such things.

The distutils-sig thread link I posted earlier discusses differences in how 
SuSE and Fedora implement their patches to Python to implement 
/usr/lib64.  The Fedora patches should work with a workaround I'm adding to 
setuptools, but I'm not sure if the SuSE one will or not.  And if there are 
other folks with different patches, who knows?

Another example of screwy distro patches is that Debian patches the 'site' 
module to add a /usr/local site-packages, but doesn't patch the distutils 
so the default installation goes there.  I've seen other distutils patches 
that change method signatures of code inside distutils.  All of these 
patches drive me bonkers because they make it impossible to enhance the 
distutils without knowing about each distro's private hacks.  If the 
distros would push back their patches, Python would at least have a chance 
of putting some API around the hacks so that they don't break things, 
especially since the patches often change only one place in Python and not 
all of the places that are actually affected by a change in directory 
layout.  These changes are especially annoying when they're things that 
have configuration variables available for them in the normal Python build 
process, sans patches.

To be fair, I imagine that distro vendors could easily say, "we put stuff 
how we wanted in the input to 'configure' and make and it didn't work, so 
we had to patch other stuff", but if they pushed back to Python-dev it 
would at least have a chance of getting fixed.


>I think it works!
>
># easy_install
>error: No urls, filenames, or requirements specified (see --help)

The real test is whether you can now easy_install things and import them 
from the interpreter without any additional work.  But yeah, you should be 
up and running now.  Sorry again for the speed bumps.




More information about the PEAK mailing list