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

Ian Bicking ianb at colorstudy.com
Tue Nov 22 00:20:56 CET 2005


Bob Tanner wrote:
>>This isn't a "problem", it's just that the Debian policy isn't
>>up-to-date.  Python eggs install this way, and many packages (e.g.
>>TurboGears) require the new structure.
> 
> 
> Then we have a problem in the Debian world. :-( Here is a snippet of an
> email I received from the Debian powers. I also believe this individual is
> one of the authors of the python-policy for Debian. I've X'd the name/email
> to protect the innocent.

I do think we need to resolve these issues with Linux distributions. 
I'd encourage the X in question to join this list, and we can discuss 
how this stuff should work.  Some of what Python Eggs do are redundant 
with a Debian package (though that redundancy can be used to positive 
effect) and some parts of Eggs offer features that don't fit into Debian 
packaging very well (like multiple installations of different versions 
of the same library, which requires versions in the package names 
themselves in Debian).

Also, .pth file management is a bit of an issue, and is something that 
should be addressed by Debian policy, as it's somewhere where packages 
should cooperate.  There are performance issues with every package 
having its own .pth file.

> ===================== snip ==================================
> 
>>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".
> "pydoc" doesn't work with eggs either.

I think there's a good argument that Python isn't quite ready for 
installing zip files, in that lots of tools don't work that well with 
them right now.  This can be addressed in code through distutils 
settings -- you can force all files to be unzipped globally in 
distutils.cfg, and perhaps Debian could hook into that (if they don't 
want to create a distutils.cfg file, which is reasonable as that can be 
useful for user configuration).

>>If it break Debian policies, please point me to the appropriate
>>section(s) and documents. I wasn't able to find any related to python
>>module packaging.
>>
> 
> zless /usr/share/doc/python/python-policy.txt.gz
> 
> 
>>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.
> ===================== snip ==================================
> 
> To comply, I added a zip_safe = False to the setup() of FormEncode, then
> moved
> 
> /usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg/formencode 
> 
> TO
> 
> /usr/lib/python2.4/site-packages/formencode
> 
> Are you saying the comply-hack- above will potentially break other python
> packages (like Turbogears)?

You lose metadata that TurboGears really wants to have; this isn't just 
dependency information, but also plugin information (which I don't think 
is being used in 0.7, but will be for 0.8).  Python packages can't be 
expected to read Debian package metadata.  Also more generally, I think 
Debian needs to play more nicely with user-installed packages, and if 
you rely purely on Debian metadata for detecting installed packages, you 
lose useful information.

As of a few months ago I've moved to Ubuntu, so I don't know what the 
exact situation is on Debian, but after learning more about distutils 
I've realized that Debian has been missing functionality that would make 
user-installed code better adhere to Debian policy (like installing into 
/usr/local/lib/pythonX.Y).  So I think Debian policy really needs some 
fixing on these matters anyway.

FWIW, Ubuntu sponsored a project for making Eggs work better there: 
http://easy-deb.sourceforge.net/ -- it doesn't mean they'll necessarily 
use that work (I have no idea what their plans are, and Google Summer of 
Code work doesn't imply anything except interest).

I'd like it to be possible to do "python setup.py bdist_deb" and get a 
Debian package; I think this should be very doable if we get some 
participation from people with Debian packaging experience.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Distutils-SIG mailing list