[Distutils] Overiding the site-packages/<module> directory name?
Phillip J. Eby
pje at telecommunity.com
Tue Nov 22 01:01:11 CET 2005
At 04:44 PM 11/21/2005 -0600, Bob Tanner wrote:
> On Monday 21 November 2005 09:09 am, XXXXXXX XXXXXX wrote:
> > > $ dpkg -L python2.4-formencode
> > > [...]
> > > /usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg
> > > /usr/share/doc/python2.4-formencode/copyright
> > > /usr/share/doc/python2.4-formencode/changelog.Debian.gz
> > >
> > > ??? Please don't do that in a Debian package.
> > First question, why?
>Because you can't us it with a simple "use formencode".
This is only true if you don't include an updated .pth file. Properly
packaged eggs should include a .pth file, or better, code to update a
single vendor-eggs.pth file. Normally, this would be done as a postinstall
and uninstall modification to a vendor-eggs.pth file in site-packages.
(I'm assuming "use formencode" should be "import formencode", btw.)
I was not aware of the pydoc problem, however it's only a problem with
*packages*, not modules, and then only if the package is zipped. For
example, with the wsgiref package, "pydoc wsgiref" fails but "pydoc
wsgiref.handlers" works fine. The issue is in fact a pydoc bug; it was not
updated properly for PEP 302, introduced in Python 2.3. It should allow
for the fact that __path__ may be empty, or that the strings contained
within it may not be local filesystem directories, and for that matter,
that the whole thing may be in a zipfile. A workaround is to install eggs
always unzipped, which you can do with the -Z option to easy_install.
I will endeavor to create a patch to ensure that future releases of Python
will fix the pydoc problem - hopefully including maintenance releases of
2.3 and 2.4, although I don't know if there will be any additional 2.3
> >Lastly that is the default installation method when using cdbs. Which I
> > just delegates it to the setup.py (ie authors choice?)
>Probably. .egg packages might be a nice generic way to ship Python stuff
>to random OS installations, but I don't think they should be used in
>standard Python packages that are shipped in a Linux distribution like
That's also not correct. Egg packaging is not merely a method of
transporting packages, but also a method of providing additional metadata
and runtime plugin capabilities, while allowing platform-independent
runtime introspection and verification of package versions. What's being
said here is like saying that Debian can only install Java .jar files if
they are unpacked and all non-code files deleted.
>Are you saying the comply-hack- above will potentially break other python
>packages (like Turbogears)?
It will force them to install a non-Debian version, since you are stripping
all the data that allows the other packages to determine whether an
appropriate version of the package is installed. In essence, you are
relegating your packaging to "legacy" status, in the sense that code which
uses the pkg_resources library to manage its dependencies will be unable to
make use of it, so from the other packages' viewpoint, it might as well not
The purpose of this packaging metadata is to allow universal dependency
management for Python software authors - they can depend on particular
versions without having to commit to a particular vendor packaging system,
simply by listing the desired eggs in their setup script.
To offer a constructive suggestion, I would propose that Debian egg
packages use 'pyegg' instead of 'python' in their naming, and that the name
be derived from the PyPI name, not the name of the contained module. This
would then hopefully allow 1:1 automated translation from egg dependencies
to Debian packages.
The thing is, the packages that need eggs are rapidly growing, and they can
potentially depend on egg versions of *any* pre-existing PyPI package. In
the long run, this means that it is most expedient to simply package *all*
Python packages as eggs, or at any rate have a tool that can automatically
translate an egg to a Debian package.
More information about the Distutils-SIG