[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