[Distutils] PEP 376, Uninstallation and interoperability

[Vinay Sajip]

PJ Eby <pje <at> telecommunity.com> writes:

> Yes - it's unnecessary for library directories (e.g. stuff under
> site-packages).  You may safely remove any empty subdirectory of the
> directories containing the .dist-info, that is a parent of any of the
> files belonging to the distribution you are uninstalling.  (In

I'm not so much concerned about that - as you say, .dist-info lives under
site-packages, so you know where site-packages is, and you *know* it's a
shared location between distributions. What you don't necessarily know is where
anything *else* is - scripts, man pages, HTML docs etc., and that was the focus
of my post.

> addition, you may optionally detect and offer to remove extraneous
> files by cross-checking against all other .dist-info records for that
> same directory -- a file not listed anywhere is an orphan.)

That might be a reasonable thing for a "clean" command to do, but it's not
necessarily something you might want to run on every uninstallation:

(a) I'm not sure, if someone has a lot of distributions, whether there might
    be a noticeable pause while all the distributions are checked.

(b) For the time being, a lot of distributions will not have all the metadata
    available - e.g. ones installed using distutils, or installed using a
    distro package manager. So the information to do this is generally not
    all there.

> Scripts, man pages, and all that are a separate issue.  I would think
> it would *generally* be safe to use the "remove any empty subdirectory
> of the relevant base directory which is a parent of a file you
> uninstalled" rule, but orphan detection would not be possible, and
> there's some possibility that you could delete an empty directory

I don't have a problem with deleting empty directories - it's more about
alerting users about directories that aren't empty, which were originally
installed into. Since you can override installation directories at the
time of installation, there is no way  that you can tell that such-and-such a
directory was used for scripts (=> likely to be shared with other
distributions), unless you record the values actually used.

> erroneously.  For that purpose, some sort of site-local configuration
> might be useful, especially if it tracks local conventions like being
> able to say that e.g., /usr/share/doc/$DISTNAME-$VERSION is the base
> directory for a package's docs and that it should be considered
> distribution-owned (and therefore removed if empty, and considered to
> have orphans if any non-project files are in it).

ISTM that what I suggested is a sort of site-local configuration - it's just
dist-local. The problem I described wouldn't arise if you could be sure that
everything was always in the same place, FHS-style. It's because users are
allowed to override locations that we need to store what their choices were
when they installed something.

Regards,

Vinay Sajip