[Distutils] Overiding the site-packages/<module> directory name?

[Phillip J. Eby]

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 
maintenance releases.


> >Lastly that is the default installation method when using cdbs. Which I
>think
> > 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
>Debian.

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 
exist.

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.