Re: Python Egg Guidelines across distros
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Josselin Mouette wrote:
> Le mardi 04 septembre 2007 à 08:28 -0700, Toshio Kuratomi a écrit :
>> 1) Do we want to create eggs where they aren't provided upstream. I see
>> that Debian's python-docutils package doesn't provide eggs in Etch but
>> you guys were willing to provide one after getting a bug report
>> requesting it. Is this the general Debian policy? Package by package?
>> Start providing eggs for everything distutils based? So far, the
>> Fedora position has been that setuptools/eggs provide the equivalent of
>> an API and therefore we should let upstream implement it, not do it
>> ourselves. This could change with good arguments.
>
> Currently, we are providing it when there is no other choice. As more
> and more mislead upstream developers are using eggs, we sometimes need
> them for some dependencies, but currently the de facto policy is not to
> generate them unless needed.
>
Understood. I'm hoping setuptools is just going through growing pains
and the author will soon start considering its limitations from our POV.
I'm not holding my breath for that, though.
> BTW I've just learned from your reply that python2.4 in Debian was
> patched to create eggs for distutils packages. This change was decided
> unilaterally by the python maintainer without being discussed here. I
> can understand the rationale for it, but I don't like the idea of
> encouraging more upstream developers to use eggs.
>
Any information on the rationale from you or the python maintainer is
appreciated by me. In deciding what kind of policy we want to adopt I'm
collecting all the information I can get :-)
>> 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?
>
> We don't and we won't ship eggs in Debian packages; we were happy enough
> to be able to ship .egg-info files instead.
>
Ah. Possibly a bit of terminology confusion here. I use egg to mean a
package which has the egg metadata attached to it. By default we ship
setuptools files using --single-version-externally managed so that info
is contained inside an egg-info directory. The Fedora guidelines I'm
working on will sometimes have us ship egg-info and source inside an egg
directory hierarchy so we can parallel install modules. So far we've
had a de facto standard of never shipping a zipped egg file. We
probably won't make a firm decision on that until someone explicitly
requests it.
> I don't think shipping supporting several versions of a package is a
> good thing in a distribution, and this should remain an exception rather
> than a rule. For cases like TG/CherryPy, you can imagine several
> solutions:
> * a conflict between both, like currently in Debian, this is far
> from ideal;
> * shipping version 2.x in a private directory and patching TG to
> add it to sys.path;
> * renaming version 2.x to something like cherrypy2;
> * use alternatives like we used to do for pygtk, but this worked
> very badly.
Yep, we've considered all of those and consider all of them to be pretty
poor. Using eggs is also pretty poor but has the advantage of being the
method supported by upstream.
OTOH, Debian has a greater history of supporting several versions of a
package than Fedora... just not python packages. (Look at the python
interpreter itself or any of the multi-versioned libraries).
Conceptually, this has precedent it's just the particulars that are new.
> Ideally TG should be made compatible with version 3 if this isn't too
> complicated.
>
I know it. Unfortunately upstream TG itself gave up the effort to port
to cherrypy3 (TG2 will be based on paste instead). cherrpy really
should have versioned their version 3 release but we're not upstream so
*sigh*.
>> 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 #3 is the stumbling block as Phillip is insisting that we need
>> to use easy_install to generate script wrappers that make the import
>> order work rather than having an API that we can count on working. I
>> have to do some more experimentation based on his last post then ask why
>> he thinks that.
>
> I don't think you need listen to anything the setuptools developers say,
> as they have close to zero understanding of the packaging issues they
> create for us.
>
Heh, I know how you feel but I try to resist giving in to it since we're
going to be living in a world with setuptools for the foreseeable future
and we'll all have to learn to communicate and compromise in pursuit of
our goals.
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG5YwGX6yAic2E7kgRAtFAAJwMgs2u+gfz2KffgOLPZ6qZDRzNzACfdTVu
MZJlaIPC5ml4QZii4P1xZQU=
=q6Y6
-----END PGP SIGNATURE-----
Reply to: