Ignacio Vazquez-Abrams wrote:

On Tue, 2008-06-17 at 00:33 +0900, David Cournapeau wrote:

...

An uninstall command is a long-time wanted feature of distutils. I was wondering why it was not implemented: what does it need to do to be useful ? AFAIK, make uninstall in autotools simply removes currently installed files, with currently refering to the current configured value of prefix and all. Isn't this enough (I am interested in a 'pure' distutils command, not a setuptools one) ? What would be the minimum semantics needed for an uninstall command ?

One of the big differences between autotools and distutils is that in autotools the destination path is set at *build* time (ignoring the not-often directly-used DESTDIR make variable, of course), but in distutils/setuptools the destination path is set at *install* time.

Yes, that's actually one of the thing I really don't like about distutils (the way options are handled), but there is nothing we can do about that in the short term. I think it would be possible to record the last install directories into the build directory of distutils, such as by default, it will remove the last installed package ? There is no question that an uninstall command will not be good for all cases; but here are some of the scenario I am thinking about: - install run uninstall before install (if uninstall info found in build): avoiding people having problems when re-installing a package without removing it first (that's my first priority, actually, but I am willing to handle other cases, of course) - uninstall a package a user does not want anymore.

Having said that, yes, it could potentially be done so that it takes the same argument as install for overriding the root, but I get the distinct feeling that people are going to forget to specify the root on uninstall quite often, thereby removing the module installed in the system location instead.

Well, there is not much you can do about that. On unix, people do not install in system location, I hope. On windows, most people install in the default location, no ? The ones who don't should be able to pass the uninstall command, normally. If we have a reliable mechanism to remove the last installed package, I think we would mostly alleviate this problem (which concern people who do not tweak much; for people who want to install in non default location, I would expect them to handle this issue by themselves ?) cheers, David

Ben Finney wrote:

I don't understand what you mean here. How do packages get into the system location if they're not installed there at some time? What, specifically, do you hope people don't do?

I meant installing packages from sources into /usr. I know some people do that under debian for example, and of course, they overwrite/mess up the package most of the time (because dpkg has already its own version there, for example). What else would you mean by system location ? cheers, David

Ben Finney wrote:

That's what the Debian packaging system would do when installing a Python package. What would you have different?

I don't understand what you are getting at. Of course the packaging system would install in /usr - which is exactly why a user should not install anything there to avoid clashing with the package manager.

The question that seems inconsistently addressed is: What should happen when installing (onto a Debian system) via distutils a Python package that *isn't* packaged yet for Debian?

Personally, I install everything into $HOME/local through stow (I don't have admin privileges at my lab). If it was meant to be system wide, I would install it in /usr/local instead of $HOME/local. I think this is pretty standard, no ? To come back at the uninstall command: the protection of the OS sounds good enough to me. If things are installed system-wide, I expect the user knows what he is doing. If the user change prefix, I also expect him to change things (most 'casual' python users I have met do not change the prefix at all, not that I claim any knowledge on typical kinds of python users). Even if I am wrong, I am not quite sure what could be done about it anyway (generally, you are not supposed to build things as root/privileged user, only install/uninstall is; uninstalling something without prefixing is not more dangerous than installing without prefixing). cheers, David

Ben Finney wrote:

We seem to have a terminological confusion here (there are many of these in discussions about Python's packaging practices).

How is the Python packaging system to distinguish between different "users" of the system? Is not the Debian packaging system a "user" of the Python distutils/setuptools?

Not in this context, obviously; otherwise, I would mean that it is not advised to install anything, which does not make sense :) The context was: how to determine which version to uninstall, assuming a given package were installed at several locations ? Someone mentioned the risk of not setting the installation directory right , which is not a concern for packagers. Some possible strategies are: - make the install directory mandatory when uninstalling ? - make the uninstall directory the one passed as prefix at the former install step, throw an error if it has not been installed yet (this is as good as we can get to mimic the autotools way, I think). - others cheers, David

chris wrote:

I've submitted a patch for an uninstall feature here:

http://bugs.python.org/setuptools/issue21

Hi Chris, Yes, I saw it. Unfortunately, it is a setuptools extension, and I don't want to use setuptools. I also want something which may be integrated by distutils at some point.

Currently it works by creating an installed_files.log file in an egg on install. This file is used during uninstall (-r option) to remove all files associated with an egg. If an egg was installed before this patch was applied, the only things missed will be external scripts.

It will also do some dependency checking. If the package being removed is depended upon by something else, it will warn the user (showing what needs that package). If the package being removed has a dependency not needed by anything else, it presents the user with the option of removing that dependency as well. Also, entries from easy_install.pth are removed.

Do you think it would be possible to refactor it to split the distutils/setuptools parts ? I could do it myself, obviously, but I don't know anything about setuptools internals. cheers, David

Phillip J. Eby wrote:

A trivial way to do it would be to have your uninstall command take a distutils installation log file as its only input argument, and then remove those files/directories. This would ensure that only packages installed using --record would be uninstallable.

Indeed. Since any uninstall command has to do this internally, it can be a useful start. What's the best way to submit something for distutils ? Python bug-tracker or somewhere specific to distutils ? thanks, David

chris wrote:

Why have only certain packages uninstallable as opposed to everything being uninstallable by default?

I did not take Phillip's comment literally: I understood that the *UI* should take the log file as an argument, not that the file itself had to be produced by --record ? cheers, David

Phillip J. Eby wrote:

Well, what *else* is going to produce it?

The install command. That's how I did a first draft, and that's how Chris did it in his patch, I think (I have not studied it carefully yet). An uninstall command which does not work without installing in a special way does not make any sense. cheers, David