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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
