[Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Phillip J. Eby]

At 10:17 PM 3/21/2008 +0000, Floris Bruynooghe wrote:
>On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote:
> > At 11:21 AM 3/21/2008 -0500, skip at pobox.com wrote:
> > >     Joachim> I think, the uninstall should _not_ 'rm -rf' but 
> only 'rm' the
> > >     Joachim> files (and 'rmdir' directories, but not recursively) that it
> > >     Joachim> created, and that have not been modified in the 
> meantime (after
> > >     Joachim> the installation).
> > >
> > >That's not sufficient.  Suppose file C (e.g. /usr/local/etc/mime.types) is
> > >in both packages A and B.
> > >
> > >     Install A - this will create C
> > >     Install B - this might overwrite C, saving a copy, or it might retain
> > >                 A's copy.
> > >     Uninstall B - this has to know that C is used by A and not touch it
> >
> > Correct.  However, in practice, B should not touch C, unless the file
> > is shared between them.
> >
> > This is a key issue for support of namespace packages, at least if we
> > want to avoid using .pth files.  (Which is what setuptools-built
> > system packages do for namespace packages currently.)
> >
> > Of course, one possible solution is for both A and B to depend on a
> > "virtual package" that contains C, such that both A and B can install
> > it if it's not there, and list it in their dependencies.  But this is
> > one of the handful of open issues that needs to be resolved with Real
> > Life Package Management people, such as Debian, Fedora, etc.
>
>Debian (dpkg) does not allow a file to exist in more then one package
>(distribution in distutils speak) as I said earlier.  Directories can
>however, they will only be removed if they are empty (i.e. when the
>last package having that directory is uninstalled).

This is a general problem with system package managers, 
actually.  Few allow a file to be provided by more than one package.

>I'm not familiar with namespace packages as I've never used one, but I
>assume it is just an empty directory with one (empty?)  __init__.py
>file in it?

It's not empty; it has to contain a namespace declaration.  There's 
another approach that can work around the absence of the __init__.py, 
by using .pth files, but it's messy, and I'd like to get rid of it if possible.


>   The only way I can see Debian handling that is by having
>a Debian package providing exactly that __init__.py and all other
>Debian packages needing that namespace package will depend on it.
>
>However, this is shouldn't worry anyone other then Debian I think.

Alas, it'll probably affect most package managers.


>  If
>a distribution needs to depend on somthing it will depend on whoever
>provides the module *inside* the namespace package, not on the
>namespace itself.  So the fact that no distribution provides the
>namespace.__init__.py file shouldn't have to worry other users of the
>python installdb.

Well, somebody still has to create the __init__.py, and own it for 
purposes of uninstallation.


>Since easy_install and others shouldn't be messing with debian
>packages in /usr/lib (they should be using /usr/local/lib or
>~/.local [1]) this won't be a problem.

If the new PEP (262 redux) contains anything about actual directory 
locations on any system of any platform (other than as examples), 
I'll consider it a failure.  Thinking about specific locations while 
talking about the new PEP should be considered a segmentation fault.  :)

The only thing that matters for the install db is where things are in 
relation to an installation target directory.  Which reminds me -- 
the install db should support install-dir-relative paths, and 
probably should require them for anything that's installed under the 
library install dir.  (Many use cases of this stuff will be 
*relative*; packaging an application as a giant tarball and unpacking 
it somewhere else on a system, or copying an application tree from 
point A to point B, should not render the data therein unusable.)