Re: [Distutils] formencode as .egg in Debian ??
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.
Reply to: