[Distutils] [Bulk] Re: formencode as .egg in Debian ??

[Phillip J. Eby]

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 
>not
>encouraged 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.)