Re: Python Egg Guidelines across distros
On Tue, 04 Sep 2007, Toshio Kuratomi wrote:
> I'm revising the Fedora Python Guidelines to make better use of eggs and
> saw an interesting bug report against python-docutils that left me
> wondering how Debian had dealt with some of the decisions that I'm
> having to make. If we come out with similar conclusions, that will be
> one less difference for end users to have to worry about between
> distros. If we come to different conclusions, at least we'll know what
> to tell users when they ask why things don't work the way they do in
> that other distro :-)
Thanks for the initiative, it's much appreciated!
We don't have a 100% clear policy, the general rule has been that we
don't provide .egg files but we provided the egg meta-informations
along with the usual modules when upstream uses setuptools by default.
In some cases, when other modules requires an egg for a module which is
not using setuptools by default, we apply a patch to use setuptools.
However I noticed lately that egg-info are systematically generated
even with distutils based modules and in fact we have
/usr/lib/python2.4/distutils/command/install_egg_info.py provided by
python2.4. I don't know when the change happened and can't find any
note on python's Changelog... Matthias?
So in practice we always provide egg-info but this change has not been
discussed here. That said I don't see a compelling reason to refuse it.
> 2) We're deciding how we want to make packages when we want to have
> multiple versions of a module. For instance cherrypy is on release
> 3.0.2 but the TurboGears framework requires a 2.2.x version. So we need
> to provide both versions to our users. I've been drafting guidelines
> for doing this using eggs_ but some recent discussions with Phillip
> Eby_, setuptools author are proving there are some difficulties to
> doing this. Have you guys considered doing anything like this?
Again, no general discussion happened on this topic but the cherrypy
maintainer packaged both versions and made them conflict (i.e. they are
not co-installable). So we report the problem back to the user who wants
to use two version of the product at the same time. :-)
$ apt-cache show python-cherrypy3 | grep Conflicts
Conflicts: python2.3-cherrypy, python2.4-cherrypy, python-cherrypy
> These are my current goals for multiple versions:
> 1) import MODULE should import whatever the vendor decided should be the
> 2) requires.txt in a project's egginfo should work to select a specific
> version from the installed eggs.
> 3) In a simple script (without requires.txt),
> should work to select a specific version from the installed eggs.
I think you're more advanced than us on this topic and we didn't not have
any plans to try to use setuptools to achieve this.
The python packaging is already complicated enough that we'd like to avoid
having to resort to such things. And in general, the Debian packagers
don't like Eggs as they replace (badly) the functionnalities of our package
manager. So we avoid promoting them and are not keen to use them to solve
new problems that shouldn't exist in the first place.
Premier livre français sur Debian GNU/Linux :