At 01:44 PM 11/24/2005 +0100, Josselin Mouette wrote:
They only introduce more complexity, instead of bringing real features.
Please read the hundreds of kilobytes of messages I've already posted on
this thread, and then when you're done, read these much shorter bits of
documentation for some examples of the features they provide:
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 are of course just the documentation for features that developers
use, in order to create features of their own. I know that Ian's SQLObject
project adds SQL-related metadata to projects using these APIs, and a
variety of projects use entry points. The Chandler PIM will probably use
project metadata for i18n stuff.
> Obviously, every individual distribution would like to have Python
packages
> conform to their individual system. However, on the whole, it is clearly
> better for the Python developer to have practical dependency management
> that doesn't tie their efforts to a single platform, packaging system, or
> distribution.
And that's why there are things like dh_python to adapt python distutils
installations to be compliant to the Debian way of things. However, eggs
make it so complicated that the adaptation layer would be
unmaintainable.
As I said, you should probably read the hundreds of K already written in
this thread before jumping to conclusions like that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
