Python Egg Guidelines across distros
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings all,
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 :-)
There's a couple different things we want to deal with in the new egg
guidelines:
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.
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?
.. _[1]:
http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs#head-818da854a807045ab05043ecf86b7e29ff5e13bc
.. _[2]:
http://mail.python.org/pipermail/distutils-sig/2007-September/008182.html
I prove my ignorance in the initial portions of the thread but towards
the end we figure some important things out :-)
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.
Any feedback on how you handle these issues in Debian would be much
appreciated!
P.S. If you could keep me CC'd to the replies that would be much
appreciated.
Thanks,
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG3XmKX6yAic2E7kgRAoTHAJ90m2lbH6wVXob59UzVJkOWAmC2RQCdEmaS
KGPzpjIl5UhAs9pGkcuQs8o=
=KOuf
-----END PGP SIGNATURE-----
Reply to: