Re: Python Egg Guidelines across distros
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raphael Hertzog wrote:
> Hi,
>
> On Tue, 04 Sep 2007, Toshio Kuratomi wrote:
> Thanks for the initiative, it's much appreciated!
>
Thanks for responding!
>
> 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.
>
> See http://wiki.debian.org/DebianPythonFAQ
>
Nice. It looks like your policies are designed to do the same things
ours were before we decided to take on multiple versions.
> 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.
>
Interesting. I knew that python 2.5 created egg-info for distutils
packages and just found out that our particular python2.5 has a patch to
disable that. Keep me in the loop as to why you guys added it to your
python2.4; it'll help me explain the benefits of removing our disabling
patch to our python maintainer.
>> 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[1]_ but some recent discussions with Phillip
>> Eby[2]_, 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. :-)
In Fedora, there's a movement to stop using Conflicts so we're trying to
figure out if we can use setuptools to manage installing in parallel or
need to come up with something ad hoc. setuptools almost meets our
needs so I think we'll go down that path for now.
>> These are my current goals for multiple versions:
>> 1) import MODULE should import whatever the vendor decided should be the
>> default.
>> 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.
Well, you guys are way more advanced in terms of multiple installed
versions of the python interpreter so that gives both of us areas we're
concentrating our efforts on. (I forsee us having to do some work to
catch up in that area in the next couple years as python2.6, python3.0,
and pypy become options different people want to use on the same system.)
> 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.
>
Oh so true :-) Python eggs, ruby gems, ... it seems that every language
is inventing a packaging format to make our lives harder these days :-)
I think eggs have some redeeming characteristics as they allow python
modules to take on the parallel installable nature of unix shared
libraries and they create a usable architecture for creating plugins.
Some days that just frustrates me more, though, as I can't quite get the
portions I want to cleanly separate from the assumptions of the portions
I don't...
Thanks for all the good info!
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG3u4aX6yAic2E7kgRAuW2AKCJl0RlORPmPdwz69EipQGilncHkACfVm4X
MfViOLqwy5lqm3M/FJ12n3I=
=NjqA
-----END PGP SIGNATURE-----
Reply to: