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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
