[Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

Paul Moore p.f.moore at gmail.com
Mon Jul 6 20:15:52 CEST 2009


2009/7/6 P.J. Eby <pje at 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.


More information about the Python-Dev mailing list