Add uninstall subcommand

[marcoesters]

Description

Uninstalling distributions for conda currently only has incomplete solutions with files and broken auto-run/initializer scripts left behind (see conda/constructor#642, conda/constructor#588, and conda/constructor#572). A clean uninstallation is currently not available without manually running a series of commands that are still not 100% safe - e.g., conda init --reverse --all will remove initialization of conda, no matter what installation it is pointed to.

This PR introduces a cross-platform uninstallation subcommand that uses conda-internal features to perform the following tasks:

• Uninstall all environments within a base environment or environments directory (such as a directory set by envs_dirs). This uninstalls all shortcuts, performs pre-unlink actions, and de-registers the environments from the environments.txt file.
• Runs conda init reverse if a configuration file points to any of the environments that are removed.
• Allows a user to remove .condarc files, either for the user, system-wide, or all.
• Allows the user to run conda clean --all to remove package caches outside the installation directory.
• Allows the user to remove cache directories, including the .conda file.

This is implemented in conda-standalone so that a single binary can be used on macOS and Linux. It also allows decoupling of the installer "front end" (built by constructor) from the installer "back end" (such as conda-standalone or micromamba), as outlined in the following issue: conda/constructor#549

Known gap: Soft links are currently not well supported: files are unlinked, but no efforts are made to ensure that this doesn't leave unused files behind.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[jaimergp]

Suggested change

	"--remove-caches",
	"--remove-additional-caches",

The term is a bit convoluted with pkgs/ and pkgs/cache being taken care of in conda-clean, but this argument targets ~/.conda and anaconda-client stuff.

[marcoesters]

Yes, unfortunately, conda overloads the term "cache". I changed it to --remove-conda-caches because it's more descriptive than --remove-additional-caches.

[jaimergp]

I still think that if a user sees both --conda-clean and --remove-conda-caches might get confused about the difference between both. Maybe the best option is to split it explicitly: --remove-anaconda-client-data, --remove-conda-notices-data. I'd argue the second one belongs in conda clean responsibilities though, so what iffff:

• The --conda-clean flag also takes care of conda notices, there's no choice. Eventually we upstream this to conda.
• Folks can optionally remove anaconda-client data.

[marcoesters]

Maybe the best option is to split it explicitly: --remove-anaconda-client-data, --remove-conda-notices-data.

I think this will result in an overwhelming amount of CLI options, especially for inexperienced users. You would then also need another flag for the ~/.conda directory. That's a total of five CLI flags of options for the first iteration.

The reason why I separated conda clean is because I can think of a use case for conda clean that isn't covered by the removing cache use case: removing all your caches, especially ~/.conda really only makes sense if you are removing the last installation on your system.

On the other hand, conda clean has its uses when you still have an installation left on your system, but share a package cache. Here, conda clean will remove unused packages and free space on your system.

[marcoesters]

I'm more amenable to the option that --clean-caches removes the notices cache and runs conda clean and that --clean-conda-data or --clean-user-data removes ~/.conda and anaconda-client data.

[marcoesters]

The more I think about this (and after talking to a conda maintainer) the more convinced I am that we shouldn't handle anaconda-client data here. This should be handled by the package instead. Otherwise, we would have to implement clean-up operations for other packages or an arbitrary selection.

I think conda-standalone should only handle conda files. So, my final proposal is:

• --clean-caches to run conda clean and remove the notices cache.
• --remove-user-data to just delete ~/.conda for now.

This also follows somewhat the XDG_* convention where we have cache, data, and configs (here .condarc files). In that case, I can also rename --remove-condarcs to --remove-config-files to allow constructor to use more generic terms.

What do you think about this solution?

[jaimergp]

Love this last proposal and the XDG rationale. I think we should stick to a verb only: either clean, clear or remove, but not a mix. So pick one (using clean as an example) and then we say:

• --clean-caches
• --clean-user-data
• --clean-config-files

[marcoesters]

I prefer remove-* because it tells the user that files will be deleted.

[jaimergp]

Should we rely on env vars like PROGRAMDATA and XDG_DATA_* for this test? Or do you think it's not necessary?

[marcoesters]

I 100% agree that we should rely on PROGRAMDATA, but unfortunately, conda doesn't use those variables: https://github.com/conda/conda/blob/main/conda/base/constants.py#L29-L42

[jaimergp]

That's probably worth an issue in conda/conda, but not a blocker here.

[jaimergp]

Awesome work! Thanks for making it all the way through the leeengthy review!