(I’m splitting off from the PEP 627 thread, but I’ll repeat the relevant information here.)
It is currently not clear how projects that are installed on a system can be uninstalled.
For background: installed projects are recorded
.dist-info directory, as specified PEP 376 (which I hope to amend by PEP 627). The directory contains several interesting files:
RECORD, a list of files with hashes,
INSTALLER, the name of the tool that installed the project, and
REQUESTED, present iff the project was not installed automatically/as a dependency.
There are several ways I (and others) can think of:
Projects can only be uninstalled by the tool that installed them. The
INSTALLERfile looks handy for this. However, if interoperability between tools is an overall packaging goal, it does not make sense to default to not touching packages installed by other tools. (AFAIK, pip nows uses this as one of its heuristics, and I believe it’s an OK thing to do in the mean time, before things are standardized.)
There are also questions related to tools delegating to each other. Tzu-ping Chung noted:
There’s actually a significant number of Conda packages out there right now packaged improperly to have their
pip. I wouldn’t worry about this too much since very few people bother to complain when pip “incorrectly” uninstalls those Conda-installed packages.
Projects can be uninstalled by removing all files listed in
RECORDis missing, then a project cannot be uninstalled (unless the tool is following other standard than PyPA: e.g. system package managers are expected to omit
RECORDand uninstall in their own way). To me this seems reasonable, but it does assume things that, I guess, might not always be true:
RECORDlists all files needed to uninstall a project
- deleting a bunch of files is sufficient to uninstall a project
Tools should record a shell command that will uninstall a project.
This looks viable, but I feel it could be tricky to pull off, especially if mixing virtualenvs (e.g. using a globally installed tool to install/uninstall to/from a virtualenv).
(It was suggested this be recorded in an existing file like
REQUESTED, but since those already exist with other content, so a new file like
UNINSTALL.shseems more appropriate.)
Or something else? Or a combination of the above?
Of course, the same questions (and more) can be asked for upgrading an installed project.