-----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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]