[Distutils] PEP 376 for Distutils

[P.J. Eby]

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.