2009/7/3 Tarek Ziadé <ziade.tarek@gmail.com>:
On Fri, Jul 3, 2009 at 4:28 PM, Nick Coghlan<ncoghlan@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.