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
>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
>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.