[Distutils] PEP 376 for Distutils

[Floris Bruynooghe]

On Tue, Feb 24, 2009 at 11:48:13AM -0800, Andrew Straw wrote:
> Ronald Oussoren wrote:
> > What about another interoperability hook for system packages: specify a
> > file that a (system) package manager can include into the egg-info
> > directory (or egg-file) to tell setuptools/pip that this egg is managed
> > by the system and hence shouldn't be removed by setuptools/pip.
> > 
> > Which such a file the user of python package tool could be warned if he
> > tries to uninstall an egg that's owned by the system, instead of
> > invoking the wrath of a sysadmin by removing such files.
> 
> But that is already implemented via file/dir permissions.

Not all systems are managed by experienced sysadmins and on many
single user systems `sudo' is all to easy to invoke.

> By your
> reasoning, we should also have something which warns users not to
> install to the system directory. These ideas are a duplication of
> functionality -- this functionality is implemented by the disabling
> write permissions of non-sysadmins into system directories.

As pointed out by PJE simply removing the RECORD file should do the
trick.

> Or do you propose users put some stuff into their system directories not
> managed by their package managers and other stuff managed by the package
> managers?

It's interesting to point out what seems to be planned for Debian:
http://lists.debian.org/debian-devel/2009/02/msg00431.html

Quoting just the relevant part:

"""
Local installation path
-----------------------

When installing Python modules using distutils, the resulting files
end up in the same location wether they are installed by a Debian
package, or by a local user or administrator, unless the installation
path is overwritten on the command line.  Compare this with most
software based on autoconf, where an explicit prefix has to be
provided for the packaging, while the default install installs into
/usr/local.  For new Python versions packaged in Debian this will
change so that an installation into /usr (not /usr/local) requires an
extra option to distutils install command (--install-layout=deb).  To
avoid breaking the packaging of existing code the distutils install
command for 2.4 and 2.5 will just accept this option and ignore it.
For the majority of packages we won't see changes in the packaging,
provided that the python packaging helpers can find the files in the
right location and move it to the expected target path.

A second issue raised by developers was the clash of modules and
extensions installed by a local python installation (with default
prefix /usr/local) with the modules provided by Debian packages
(/usr/local/lib/pythonX.Y/site-packages shared by the patched "system"
python and the locally installed python.  To avoid this clash the
directory `site-packages' should be renamed to `dist-packages' in
both locations:

 - /usr/lib/pythonX.Y/dist-packages (installation location for code
   packaged for Debian)
 - /usr/local/lib/pythonX.Y/dist-packages (installation location
   for locally installed code using distutils install without
   options).

The path /usr/lib/pythonX.Y/site-packages is not found on sys.path
anymore.

About the name: Discussed this with Barry Warsaw and Martin v. Loewis,
and we came to the conclusion that using the same directory name for
both locations would be the most consistent way.

This change should make the request to conditionalize the inclusion of
/usr/local/lib/pythonX.Y/site-packages into sys.path obsolete.

If needed we can provide a symlink /usr/lib/pythonX.Y/site-packages
pointing to dist-packages.
"""

This should address the concern of sysadmins making mistakes when
adding and removing python distributions (packages/modules).  In other
words, maybe it's not python's problem but the OS distribution's
problem.

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