At 01:50 AM 2/24/2009 +0100, Tarek Ziadé wrote:

I having the same problem with the version : since it is already located in PKG-INFO, there's no need to have it in the folder name;

It's there so pkg_resources doesn't need to read the file in order to locate an available version of the package, just the listdir() that it was doing anyway. In other words, it's a performance optimization, and a pretty major one when you're building an Environment object to look for available package versions. Cuts down on a LOT of file opens in the case where you have a ton of .egg-info's in site-packages, like on a Linux system with Python 2.5. Now, it is supported to leave that information out, but that's really intended only for working with development packages/checkouts, where you don't have so many of them on sys.path at any one time that the extra open is a big deal.

In Distutils, there should be one egg-info per package. (While setuptools multi-package options allows to activate/deactivate various versions of the same package).

That said, I don't think this PEP should address multiple versions issues.

Note that sys.path could have more than one version of the same package on it, in two different directories. (Granted, one would take precedence over the other, but that should still be explicit.)

PEP, because as far as I can see, the namespace package boilerplate in setuptools is using pkgutil.extend_path which fixes __path__ variables on the fly. So I can't think of a case where a static __init__.py file will be shared, thus removed.

When a distutils package does it. I'm not positive, but if 'pip' supports namespace packages without using .pth files, then it has to use a shared __init__ also. And in the long run, easy_install will do this too. So, the uninstallation code should simply not remove file(s) that are referenced by more than one manifest in the target directory -- a relatively simple, future-proof safeguard, that doesn't require any specific knowledge of "namespace packages" per se.