Add `conda self uninstall` command

[jezdez]

Summary

Add a conda self uninstall command to cleanly remove the conda installation from the system, similar to rustup self uninstall.

Motivation

There is currently no supported way to cleanly remove a conda installation from the command line. Users have to manually delete directories and clean up shell configuration. A conda self uninstall command would provide a safe, guided removal process.

Proposed behavior

• Remove the conda base environment and all its contents
• Clean up shell integration (e.g., conda init modifications to .bashrc, .zshrc, etc.)
• Optionally remove all other conda environments
• Require explicit confirmation (e.g., --yes flag)
• Print a summary of what will be removed before proceeding

Open questions

• Should this remove all conda environments or only the base environment?
• Should it offer to keep a backup of environment specs (e.g., export all environments before removal)?
• How should it handle the fact that conda is running from the installation being removed?

[jezdez]

cc @marcoesters

[marcoesters]

There is currently no supported way to cleanly remove a conda installation from the command line.

conda-standalone provides a pretty comprehensive one: https://github.com/conda/conda-standalone/blob/b787b58860488ec43129b017ffd474f3986ff342/src/conda_constructor/uninstall.py

How should it handle the fact that conda is running from the installation being removed?

This is only a problem on Windows, which will leave .conda_trash files behind. There isn't much you can do about it except for directing the user to manually remove the directory. You can mark them for deletion, but that requires writing to HKLM, so may need admin privileges.

[jezdez]

Implementation approach: reading existing installer metadata

After investigating what installers already write to disk, the uninstall command can detect the installation origin without any new plugin hooks or registry formats:

Constructor (Miniforge/Miniconda):

• conda-meta/history first line: # cmd: constructor ...
• conda-meta/initial-state.explicit.txt: original package list

conda-express (cx):

• Currently writes .cx.json, but Replace .cx.json with constructor-compatible metadata conventions jezdez/conda-express#66 proposes switching to the same constructor conventions (history + initial-state.explicit.txt with # cmd: conda-express ...)

pixi:

• conda-meta/pixi (JSON with manifest path, env name, pixi version) -- pixi-managed prefixes should refuse uninstall since pixi owns them

Proposed uninstall flow

1. Check for conda-meta/pixi -- if present, refuse with "this prefix is managed by pixi"
2. Read conda-meta/history first # cmd: line to identify the installer (constructor, conda-express, or unknown)
3. Confirm with user (show prefix path, installer origin, env count)
4. Clean shell init files (conda init --reverse or equivalent)
5. Optionally remove all conda environments (if user confirms with --all)
6. Delete the prefix via a detached background script (avoids the "deleting the running Python" problem)
7. Print a goodbye message with reinstall instructions based on the installer origin

The "sawing off the branch" problem

conda self uninstall runs from the Python inside the prefix it wants to delete. On Unix this works (you can delete files under a running process), but cleanup is cleaner with a detached script:

• Phase 1 (Python): collect paths, clean shell init, write a temp cleanup script
• Phase 2 (detached sh/bat): sleep briefly, rm -rf the prefix

This is the same approach Homebrew and similar tools use.

[jezdez]

Draft PR #159 advances this with the generic command and dispatch boundary:

• conda self uninstall is now a thin conda-self command
• removal is implemented by a private installer adapter that claims the current root prefix
• conda-self does not infer ownership from history or guess how to delete an installation
• without an uninstall adapter, the command refuses and points the user back to the installer or package manager

The follow-up for this issue is now an installer adapter, not more generic deletion logic in conda-self. A Constructor adapter could cover Miniconda and Miniforge-style installations when their installer metadata proves ownership. It would own the removal plan, shell cleanup, confirmation, detached deletion, and Windows-specific guidance.

Other owners can provide different behavior. An external package-manager adapter should refuse and print its exact update or uninstall command. A standalone launcher adapter can use its own installation receipt.

I would keep this issue open until at least the Constructor path is implemented and tested. PR #159 supplies the shared primitive and user-facing command only.