[Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond
Phillip J. Eby
pje at telecommunity.com
Fri Mar 21 23:30:33 CET 2008
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.
>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
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 ) 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.)
More information about the Distutils-SIG