At 03:30 PM 11/25/2005 +0100, Vincenzo Di Massa wrote:
Alle 15:05, venerdì 25 novembre 2005, Phillip J. Eby ha scritto: > It seems to me like the simpler solution is just to have the packages > install the .egg-info, and nobody has to maintain a mapping database > because the setup.py's the .debs are built from already have the info > needed, and there's no special code having to be jointly maintained to make > the detection work. The simpler solution has pitfalls consisting of: 1) you need rebuilding every single python, rpm, tgz... package
Only those, such as ElementTree, that are depended on by a setuptools-based package, such as TurboGears. While this will be increasingly widespread over time, that doesn't mean that Debian needs to rebuild all those packages *now*, unless that's what is desired.
2) as you told it has problems with namespace packages that coud be resolved providing more hooks ( http://mail.python.org/pipermail/distutils-sig/2005-November/005542.html )
Your approach doesn't fix this; it's a fundamental problem with the standard distutils package layout. The only simple fix for namespace packages is to use .egg directories for projects that use them. If that's not acceptable, namespace packages will need to use the "dummy Debian package for the __init__.py" approach.
Currently, only PEAK, Paste, and maybe some of the LivingLogic packages actually use namespace packages in the field, so far as I know. Zope 3 makes heavy use of namespace packages, but is still in the early stages of moving to eggs, so I'm pretty sure they don't have any eggs with namespace packages yet. I believe they are only using eggs for Zope 2 plugins so far, not actually distributing Zope 3 or Zope itself that way.
So, I don't believe namespace packages are an immediate issue for Debian, but they might be soon, depending on whether TurboGears starts using Paste packages. I believe TurboGears 0.9 or 1.0 might have some plans to leverage PasteDeploy for creating applications that will be launchable by WSGI servers.
3) you must provide functionality to distributors when they need (they are notencouraged to "subclass" your project and do what they want) (what when fedora or mandriva disagree with you or with Debian? will you add more and more platform specific --do-this-if-you-are-on-Debian-Sarge-with-backports and --do-this-if-you-are-on-Fedora-3.0?) :-)
Actually, I'm increasingly tempted to PEP the idea of a name-version.pkg-info file being installed alongside the code as a standard Python distutils feature. This discussion has made it clearer (even to me!) how useful such a thing would be, and if it became a standard part of the distutils, it would simply become part of Debian and every other system packager unless explicitly removed.
Such a thing would compete with PEP 262, but PEP 262 also seems like more competition with system package managers than this idea is. Arguably, normal Python code doesn't need all the extra baggage in the PEP 262 database; the PKG-INFO part alone is sufficient when there's an existing system package manager. And if you don't have a system package manager, using eggs solves most of the other problems PEP 262 was intended to address.
Perhaps it's worth a show of hands on Distutils-SIG, as far as whether there are any people (Marc-Andre? Martin? Paul?) who are outright opposed to making .pkg-info files be a standard feature of distutils installation, as a simpler substitute for the sketchy state of PEP 262. If there's nobody actively opposed, it might well be worth PEPping. At that point, it would be an easier sell to package system maintainers, in that it would be expected for Python 2.5, and courteously requested as an advance feature with current Pythons to support leading-edge software development using Python.
(Note that such a PEP would *not* be an endorsement of any .egg format, setuptools, or the concept of eggs in general, which is why I would propose .pkg-info rather than .egg-info there, in order to avoid any premature implication that eggs are a standard Python feature. Changing setuptools to support the alternate naming is a trivial matter with negligible performance or other impacts.)