[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 03:49 PM 11/24/2005 +0100, Matthias Urlichs wrote:
>Hi,
>
>Christopher Lenz:
> > (And no, I'm not going to repeat the numerous attempts by Phillip to
> > politely and comprehensively explain it all.)
> >
>Sorry -- I don't buy that. I've read all these messages too, and I also
>don't know what's in the metadata besides dependency information.

Whatever the project developer wants to put there, or wants people creating 
projects that use his project to put there.  It's essentially an 
inter-project communication and configuration system:

http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins

http://peak.telecommunity.com/DevCenter/setuptools#defining-additional-metadata

http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages

http://peak.telecommunity.com/DevCenter/PkgResources#entry-points

http://peak.telecommunity.com/DevCenter/PkgResources#metadata-api


These features are already being used by Trac, TurboGears, SQLObject, 
Paste, and others.  Other projects are contemplating moving to the use of 
egg entry points to improve their extensibility, or increasing the use that 
they currently make of these features.


>Debian, rpm, and other Linux packaging systems don't need to install
>Python-specific dependency information in their packages.
>
>It's probably nice to have so that non-system Python packages can complain
>properly, instead of throwing an incomprehensible exception later (and
>leaving one with a partially-installed system or whatever), but that's a
>different problem.

That's an interesting perspective, but it's viewing the world through 
vendor-colored glasses.  Unless the project developer is wearing similar 
glasses (i.e., has decided to commit to Debian as their sole platform), 
though, it's not a practical one.  From the point of view of people like 
the author of TurboGears, it's the egg dependency system that allows them 
not to have to worry about which packaging system the user has, or doesn't 
have.

I mention this not to be disagreeable, just to point out that the world in 
which egg dependencies are of no benefit, needless complexity, etc., is not 
the same world in which the project developers using eggs live.

Case in point: this thread began because somebody wanted to package 
TurboGears and its dependencies for Debian.  But that project wouldn't have 
been viable without the egg system already existing, and there was 
certainly no way for TurboGears to have started its life as anything but a 
"non-system Python package".  One reason TurboGears is popular is because 
it's well-supported, and it's well-supported in part because it can 
"complain properly" (as you describe it above) no matter what platform it's 
running on.

Another reason TurboGears is popular because of its high degree of reuse of 
existing code.  Indeed, TurboGears has an unprecedented degree of reuse of 
code for a Python project.  How many Debian Python packages have even 
*half* as many Python dependencies as TurboGears does?

Meanwhile, TurboGears is viral with respect to eggs.  When you create new 
web applications with it, those projects are also eggs, with dependencies 
on TurboGears.  And of course people are creating TurboGears add-ons, like 
the identity package, and those have dependencies to TurboGears and other 
eggs.  Even if it were *only* TurboGears that was doing these things (and 
it's not), you're going to have an "egg-splosion" on your hands here pretty 
soon.  ("Pretty soon" == ~1 year, assuming the current growth rate of eggs 
is linear rather than exponential.)

Again, I don't think you're "wrong" to think that egg dependencies are 
redundant - from within your particular point of view.  But you need to 
understand that for *Python* developers, being able to practically depend 
on other packages in a cross-platform way is a new and powerful feature 
which is *not* provided by Debian or any other packaging system, unless 
it's wrapping eggs.  So, from your perspective, you already have this 
feature, but for projects using eggs, you really *don't* have the feature, 
because the data is not economically accessible to them.

And that's only *one* feature of eggs, not even getting into each new 
egg-specific feature that each project can create, building on the entry 
point and metadata features.  Of course, those features have a different 
growth curve for adoption than the dependency features do, since plugin 
features are more of a hub-and-spokes model with limited network 
effects.  And an individual plugin project is less likely to need to end up 
as a Debian package anyway, so the plugin impact will be more slow-moving 
unless somebody puts out a "killer app" that everybody wants plugins for.

Anyway, I appreciate your frank and open-minded participation in this 
discussion, and I hope that together we can get the remaining issues resolved.