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