[Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

[Stephen J. Turnbull]

Floris Bruynooghe writes:

 > [dist-packages] is a pretty neat solution to the problem.

To what problem?  I admit I am no expert on Python packaging, but my
experience with XEmacs suggests that this is the distro trying to help
with a *set* of problems that the user/sysadmins really should be
handling themselves.

There are varied requirements that lead to a need for yet another
place to install modules, but there's no guarantee that a given
user/sysadmin has *just one*.  With the Emacsen, often in trying to
satisfy several requirements they end up with conflicts (different
libraries in the site-lisp that are compiled for, or even require,
different versions of (X)Emacs or even trying to deal with Emacs and
XEmacs simultaneously).  And it's a pain (as an XEmacs maintainer) to
have to field questions about why things don't work in a set up I
didn't design, and don't understand the rationale for.

 > Generally it seems accepted that installing modules in the system
 > location (/usr/) is a bad thing, but last time it got discussed
 > there was a point blank refusal to accept that the local admin
 > needs a location in to install packages in.  I think it would be
 > great if Python instead provided a general guideline or best
 > practice for this situation which would be explained in the
 > documentation.

Yeah, so do we all, but I suspect that for Python, like the Emacsen,
there is *no* general guideline.  You're just asking for various kinds
of trouble, all of which require expert attention, by installing a
command that is invoked as "python" (as opposed to "pythonX.Y") in
/usr/local/bin unless you intend it to be a complete substitute for
the system python.  And that itself is a serious tour de force (as
anybody who remembers Red Hat's love affair with Python 1.5.2 will
agree, I suspect).

As far as I can see, *in general* /usr/local/lib/python/site-packages
is the right place to install local packages for use with the system
python, and no other.  That doesn't mean that there aren't *other*
valid uses for that location, just that I see no general rule for
supporting *all* of them at the same time.