One of Python's problems with packages
December 7, 2008
One of the problems with Python's current approach to CPAN-like packages is, to put it in a particularly blunt way, that it hasn't quite sunk in that not everyone has root.
(I am aware that Python doesn't have an approach to packages as such; it's all done by distutils et al, although distutils is part of the standard library. That's part of the overall problem.)
Oh, sure, you can use distutils to install packages in places besides
the system locations. And then your Python programs won't automatically
find them so that you can
(Also, even if you have root level access, there is always the CPAN problem.)
That it is non-trivial to use canned packages is, I think, one reason that something like the CPAN culture does not seem to have really caught on in the Python community. My own experience was that I would rather write my own WSGI system (admittedly partly for the learning experience) than go through the hassle of trying to pull in the existing wsgiref module (in the days before it was part of the standard library).
(In theory you can just dump simple modules into your program's or
package's directory and
As I hinted earlier, one of the core problems is that handling packages has been left to Python modules. A really useful package system really does require the cooperation and involvement of CPython itself in some way; without this, there's only so much that distutils or anything else can do. However, I have to admit that I don't really know what CPython should do to improve things. It has fairly good reasons for not automatically running user specifc code or searching user package directories every time it starts, and there are mechanisms for overriding this; it's just that they're inconvenient, and I think that the inconvenience is high enough that they create real friction.
Comments on this page:
* * *
Atom feeds are available; see the bottom of most pages.