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

[Floris Bruynooghe]

On Fri, Mar 21, 2008 at 10:04:45PM -0400, Phillip J. Eby wrote:
> At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
> >However, I'm extremely skeptical that this can ever succeed
> >to the degree that whoever provides RPMs, .debs, or MSI
> >files will actually use such data, as they will find that
> >the data are incomplete, and they have to redo all of it,
> >anyway.
> 
> The data isn't for them to use to meet their use cases, it's for them 
> to *provide* so that Python tools don't stomp on, uninstall, or 
> otherwise interfere with files installed by the system.  In other 
> words, for system packagers, it's a communication from the system to 
> Python, rather than the other way around.  Even though the distutils 
> will build the file in the bdist, the system packaging tools would be 
> free to generate their own file listing and signatures and such.

As long as systems (dpkg, rpm, ...) install the .egg-info files they
do communicate which modules/distributions are installed.  The
installdb would just duplicate this information (according to the
current PEP).


> >>And as I said, I'll be happy if all we do is get the distutils to 
> >>abide by the spec for 2.6, even if it means we don't get an 
> >>uninstall tool.  That can always be installed later using Guido's 
> >>bootstrap tool.  :)
> >
> >I'm even more skeptical here. If the assumption is that the package
> >database allows for uninstallation, I'm -1. IOW, RPM, deb, MSI
> >should then *not* write to that package database, as they also write
> >to a different database, out of the scope of the PEP, and this is
> >what uninstallation should use.
> 
> I probably should have brought this up, in fact, I think I mentioned 
> it in a previous thread, but I would like to see PEP 262 add a way to 
> say "this is a system-installed package, *don't touch*".  The idea 
> again is not to do the job of the native packaging system, but rather 
> to ensure that Python-specific tools (e.g. easy_install and friends) 
> do not interfere or conflict with it.
> 
> A big problem in the early development of easy_install, even using 
> eggs, was that there was no way to tell whether it was safe to delete 
> or overwrite an existing file or directory that was already installed 
> on the system.  A mechanism like this would allow tools like 
> easy_install to say, "oh, your system packager has a conflicting 
> package here, you need to use that tool to sort this out if you 
> really want to do something here.  I'm not going to touch 
> that."  Without something like this, there is no way to tell the 
> difference on many systems between a system package and something the 
> user has put there with "sudo python setup.py install".

There is a way of telling if you have to keep you hands off a package
(sorry to bring this up again): installation paths.  /usr/lib is the
system path, the local admin (and hence setuptools) should keep their
hands off it at all times (unless requested with a --prefix or so for
building the debs or rpms but an uninstall in those cases won't be
required from setuptools).

What an installdb could help with is tell setuptools to keep it's
hands off a distribution manually installed (or by another tool) in
the local admin directory (/usr/local) or user directory (~/).  Your
proposal of an installdb for each directory on sys.path would solve
this, but the installdb in /usr/lib will be completely usused.

But frankly, for that just an extra field in the .egg-info
"Installed-By: setuptools" would do no?  Possibly followed by a
"X-Setuptools-Installed-Files:" section if you need that.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org