[Distutils] PEP 376, Uninstallation and interoperability

[Daniel Holth]

On Feb 18, 2013 3:32 AM, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>
> 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.

If you want eby-style uninstall to be fast, index record in sqlite in a
post-install hook.

I'm horrified that "overwrite any file on my system" is a feature. I think
gem and npm get along without it, if you want to write into /etc then you
should be building rpms.

Bento (used to?) optionally write the install scheme to a .py file named by
the package author. Just lines of variable assignments path name =
"some-path". And only if your program needs it at run time.

It doesn't have to be another all capital letters filename in dist-info
either. In the old system all the egg-info metadata was lowercase file
names except PKG-INFO. Somehow uppercase has become the new style. I am
guilty of it as well with WHEEL.

For the uninstall, recording created directory names in record is the most
potentially sensible thing. It feels very wrong for the uninstaller to care
about which folders are scripts and docs. You will have to explain more
clearly to convince me.

Daniel Holth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130218/9bdeb14a/attachment.html>