[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 06:13 PM 11/24/2005 +0100, Josselin Mouette wrote:
>Le jeudi 24 novembre 2005 à 11:43 -0500, Phillip J. Eby a écrit :
> > 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.
>
>As I understand your explanation, developers who are using eggs are
>doing it so simplify *their* work, without a thought for users. Tools
>that simplify development processes are good and should be encouraged,
>but not if it means extra burden for users.  One of the primary
>priorities of the Debian project is its users. Obviously this isn't
>yours.

You seem to be confusing "users" with "Debian packagers" and "Debian 
users", which are a subset of "users" where these projects are 
concerned.  TurboGears targets Mac and Windows as well as Linux, and I've 
seen people on the TurboGears mailing list using at least three major 
packaging *tools* (e.g. .rpm, .deb, etc.), to say nothing of the count of 
Linux *distributions*.  Obviously, Kevin *was* thinking of the users - eggs 
are the only thing that would let his project reach so many of them.


> > 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.
>
>Again, the ability to distribute it as a single package is good,

What "single package" are you talking 
about?  http://turbogears.org/download/ lists eggs and source packages for 
*10* different Python projects that it depends on, written by five 
different authors.  Each is individually packaged, with eggs for Mac and 
Windows, and source packages that can build eggs for everything else.


> > 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.
>
>Yes, having that information is good. But there should be a way to
>ignore it. Simply. Nothing more, nothing less. If egg-enabled packages
>can also work without all this extra stuff, there's no problem for the
>distributor.

What you're saying is, you want TurboGears to be able to blindly trust that 
its dependencies are installed.  This doesn't help users, though, because 
it keeps the package author from being able to provide *end-user support* 
without learning the ins and outs of every distro and packaging system, so 
he can tell the user what to run to find out if the dependencies are 
*really* met.

The funny thing here is that just the .egg names *alone* have been wildly 
useful; when a user posts an error message to the TurboGears mailing list, 
you can tell right away exactly what the project versions are for every 
piece of code in the stack trace.  It dramatically cuts down on the number 
of, "Do you have version X of Y?" questions.

Being able to support users is good for users.  Being able to provide lots 
of functionality using off-the-shelf libraries that have their own 
documentation is good for users, too.  This is *all* about the users.