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

[Nick Coghlan]

P.J. Eby wrote:
> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>> But if it's based on PEP 302 protocols and if the pkgutil code works
>> with the sys.meta_path hook,
>> setuptools could then provide its loader, based on its EggFormats and
>> act as a provider without being broken.
> 
> You misunderstand me.  The whole point of putting .egg-info in distutils
> in the first place was to enable setuptools to detect the presence of
> disutils-installed packages.  That's what's broken by changing the name.

How much information does setuptools actually need in order to tell that
a distribution is already present? Presumably the existing .egginfo
files generated by distutils are sufficient for that task?

If so, I'd still prefer to keep the new metadata safely out of reach of
the legacy package management systems that don't understand it, while
having distutils retain the ability to generate a legacy ".egginfo" file
to warn off the existing package management tools from installing the
same distribution again.

So instead of ".egginfo becomes a directory" as in the current version
of PEP 376, the existing distutils .egginfo file generation would
instead remain unchanged with a ".pydist" directory being added
alongside to hold all the new goodies. That way, the legacy formats
(EGG-INFO, .egg-info file, .egg-info directory) continue to play as well
together as they do now, while the new distutils system will understand
.pydist directories natively and allow the injection of hook
implementations by the third party package management tools in order to
understand the old formats.

That seems like it will give us the best of both worlds - a clean base
to work from in the future, but without breaking the existing
interoperability mechanisms (at least in the short term - maybe by the
time 3.3 rolls around we will be able to start thinking about
deprecating the legacy .egginfo formats, but even considering that
question is a long way off).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------