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.
> 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,
> 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.