2009/7/6 P.J. Eby <pje@telecommunity.com>:

At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:

...

...

...

So is PEP 376 going to be able to cope with the stuff I have installed at the moment? If not, what's the point???

If I understand Tarek's proposal correctly, then no, it will not cope.

Why that ? Can you detail ? On a system that uses only plain distutils distributions, it'll work.

Paul's question, as I understood it, was whether pkgutil would handle the existing .egg-info's.  Your proposal, as I understood it, was that pkgutil would not detect .egg-info's without a plugin of some sort...  and you've not proposed a way of loading such a thing, which means that to use pkgutil with that plugin, an application would have to know that the plugin exists and import it.

Close. My point was that distributions which use setuptools in their setup.py, *even if there's no runtime dependency on setuptools* end up with non-standard .egg-info's. There is no good reason for this, from my POV as a package user. So if setuptools is breaking otherwise entirely standard packages, so that they won't work with core distutils mechanisms, that's wrong. Setuptools is refusing to play nicely with other packaging systems. Now at the moment, this is a moot point, because the stdlib doesn't have any package discovery mechanisms. But when they *do* appear, I expect setuptools to work with them. So, when PEP 376 is accepted and implemented, I contend that, in order to be a well-behaved packaging tool, setuptools must: - Generate PEP 376 compatible metadata - Recognise PEP 376 compatible metadata - Unless installing a custom package format (such as eggs), which has its own PEP 302 installer, refrain from installing hooks that alter the way the standard distutils commands handle metadata. That's my view as an end user of Python packages. It means that if I choose not to use setuptools/easy_install to manage my packages, I shouldn't need them so that distutils or other core utilities (such as bdist_wininst) can do so.

Unless you're planning to have a plugin registration facility (ala entry points) so that plugins can be used without each application needing to discover them on its own?

My understanding was that package management tools provide their own end-user level install and uninstall features (the PEP 376 uninstall is just for filesystems, to correspond to the distutils install command). PEP 376 is just standardising the format of metadata, and the APIs to allow read access. The PEP 302 hooks I'm writing provide the "plugin" ability for alternative storage formats. But there's no provision for alternative *metadata* formats. What's the point of a standard if people don't follow it? Paul.