[Python-Dev] PEP 376

[Paul Moore]

2009/7/3 Tarek Ziadé <ziade.tarek at gmail.com>:
> On Fri, Jul 3, 2009 at 4:28 PM, Nick Coghlan<ncoghlan at gmail.com> wrote:
>> I will note (and I believe this is also the main point that Lukasz was
>> making) that having the distribution metadata outside the distribution
>> as currently proposed in PEP 376 is going to make any eventual PEP 302
>> integration much harder - 302 importers only provide a mechanism for
>> accessing files inside the distribution, not "adjacent" to them, so the
>> mechanism in the PEP doesn't generalise properly.
>>
>> I suspect this limitation of the PEP 302 APIs is the origin of the
>> setuptools format that embeds the metadata inside the distribution - it
>> lets you get at the metadata without having to assume that it exists
>> directly on the filesystem anywhere.
>
> Maybe we could rework the pkgutil classes for PEP 376 so they look
> like an implementation
> of the PEP 302 protocol for directories and zip files, with an extra
> "get_metadata()" API
> and state that it could be an extension for PEP 302 later.

That sounds like an excellent approach And given that PEP 302 is
nothing more than an API spec, it's nice and easy to extend PEP 302 to
say that importers can/should implement this (after all, the only 2
"real" cases in the wild are done, via PEP 376).

Warning: I've not thought all this through fully, so I may be missing
some subtleties! The ultimate spec needs to be clearly worded, and as
a consequence of this discussion it occurs to me that the current PEP
376 is very far from clear in defining exactly what the naming, layout
and location of egg-info directories is - it makes a lot of
assumptions that may break for more general path importers

I'll do some thinking, and maybe come up with some examples of PEP 302
edge cases, so that we can at least be sure that they've not been
ignored (rejected as to stupid to care about, on the other hand, I'm
happy with :-))

Paul.