# How to Uninstall Conda Packages for Bioinformatics By the end of this guide you will be able to remove a single Conda package from a bioinformatics environment, preview exactly which dependencies come with it, delete an entire environment, roll back a removal, reclaim the disk space Conda leaves behind, and verify every step with commands that print their expected output. You will also learn the mistakes that break analysis pipelines, and why container-based workflows often make uninstalling unnecessary. To follow along you need a Linux or macOS workstation or an HPC login node with Miniconda or Anaconda installed, a terminal, and at least one Conda environment containing a bioinformatics tool. All commands are standard Linux commands for bioinformatics work and should run unchanged in bash on Ubuntu, CentOS, Rocky Linux, or macOS. ## Why uninstalling matters in bioinformatics Conda is the dominant package manager for command-line bioinformatics software because the Bioconda channel alone distributes more than 3,000 packages maintained by a global contributor community, and because it lets users build isolated environments with pinned software versions without administrator rights [1]. Most published tools now ship through it. The bit collection of utilities for FASTA manipulation and assembly statistics is conda installable [2], the mass spectrometry library spectrum_utils is designed for easy conda installation [3], the coalescent simulator ipcoal is distributed for packaged installation with conda [4], and capC-MAP for Capture-C analysis is available through the conda package manager [5]. The same convenience creates clutter. A typical RNA-seq environment accumulates aligners, QC tools, and annotation utilities over months of work, and each tool drags in dozens of compiled dependencies. Uninstalling cleanly matters for three reasons: 1. **Reproducibility.** Bioconda's core value proposition is isolated environments with defined versions. An environment full of leftover packages from abandoned analyses is hard to export, hard to share, and hard to reason about when a reviewer asks which tool produced a figure. 2. **Disk space.** Genomics tools such as BWA, GATK, and their bundled libraries can occupy several gigabytes per environment, and Conda caches every downloaded package archive separately. 3. **Avoiding version conflicts.** A stale package can pin an old shared library, such as a specific `libstdc++` or `zlib` build, that blocks upgrades of tools you actually use. A related point for anyone curating software: the Galaxy and Bioconda packaging tutorial emphasizes that the same channel machinery that installs tools cleanly also makes them easy to update and retire in a controlled way. Uninstalling is the other half of that lifecycle. ## How Conda organizes software (and why removal behaves the way it does) Three concepts explain almost every surprise you will hit when uninstalling: **Packages** are versioned archives, for example `samtools 1.19.2`, placed in environments. **Environments** are self-contained directories under `~/miniconda3/envs/` (or `~/anaconda3/envs/`) that hold packages and their dependencies. **The package cache** is the `pkgs/` directory under your Conda installation, where Conda stores downloaded and extracted archives so multiple environments can share them through hard links instead of copying files. Because dependencies are shared across environments through that cache, `conda remove` removes a package from one environment and leaves the cached archive on disk for other environments. This design keeps environments small and installs fast, but it means "uninstall" and "free disk space" are two separate operations. This guide treats them separately. Another practical note: if you have a Jupyter-based workflow such as a Genomics to Notebook session, a JupyterLab kernel that pointed at a removed environment will stop working, so check which environments host kernels before you delete anything [6]. ## Step 1: Survey what you have before removing anything Never remove a package blind. First list your environments: ```bash conda env list ``` Expected output: ``` # conda environments: # base /home/you/miniconda3 rnaseq * /home/you/miniconda3/envs/rnaseq assembly /home/you/miniconda3/envs/assembly ``` The asterisk marks the currently active environment. Then list the packages in the target environment, filtered with `grep`, one of the most useful everyday Linux commands for bioinformatics housekeeping: ```bash conda list -n rnaseq | grep -i samtools ``` Expected output: ``` htslib 1.19.1 h81da01d_2 bioconda samtools 1.19.2 h50ea8bc_0 bioconda ``` Two details matter here. The `bioconda` entry in the Channel column tells you the package came from the Bioconda channel rather than pip or the defaults channel. And `htslib` appears above `samtools` because samtools depends on it. When you uninstall samtools, Conda may also remove `htslib` if nothing else in the environment uses it, which is exactly the behavior you should preview before committing. Save a record of the environment before touching it. This file is your insurance policy and, in settings where software changes must be documented, such as validated or Good Manufacturing Practice analysis environments, it doubles as your audit trail of exact versions [7]: ```bash conda env export -n rnaseq > rnaseq_backup.yml ``` ## Step 2: Preview the removal with a dry run This is the single most valuable habit in this guide. Add `-dry-run` and Conda shows the plan without changing anything: ```bash conda remove -n rnaseq samtools --dry-run ``` Expected output: ``` ## Package Plan ## environment location: /home/you/miniconda3/envs/rnaseq The following packages will be REMOVED: htslib-1.19.1-h81da01d_2 samtools-1.19.2-h50ea8bc_0 DryRunExit: Dry run. Exiting. ``` Read this list carefully. If the REMOVED section is short, the package was mostly self-contained. If it lists dozens of packages, or if it also lists packages under "will be DOWNGRADED" or "will be UPDATED", other tools in the environment depended on the one you are removing and the solver is rearranging the rest of the environment to compensate. In that case, reconsider whether you actually want the removal, or whether rebuilding the environment from a clean `environment.yml` would be simpler. ## Step 3: Remove the package The actual uninstall command is short: ```bash conda remove -n rnaseq samtools -y ``` The `-y` flag auto-accepts the plan you already reviewed with the dry run. You can name several packages in one command: ```bash conda remove -n rnaseq cutadapt multiqc fastqc -y ``` Expected output ends with: ``` Preparing to transaction: ... done Executing transaction: ... done ``` If you prefer faster solves on large environments, `mamba remove` accepts the same arguments and resolves dependency changes much faster, which matters when an environment holds hundreds of packages: ```bash mamba remove -n rnaseq samtools -y ``` ## Step 4: Verify the removal Verification takes two commands. First, confirm Conda no longer tracks the package: ```bash conda list -n rnaseq samtools ``` Expected output when the package is gone (you may see only its former dependency, or nothing matching): ``` # packages in environment at /home/you/miniconda3/envs/rnaseq: # # Name Version Build Channel ``` Second, confirm the executable is actually gone from the environment's `PATH`. `conda run` executes a command inside the environment without activating it: ```bash conda run -n rnaseq samtools --version ``` Expected output: ``` command not found: samtools ``` On the shell side, `command -v samtools` returns nothing (and prints nothing) when the binary no longer exists on your PATH, which is the standard POSIX check. If `samtools` still resolves, it is probably installed somewhere else, such as `/usr/local/bin`, from an older manual installation, and Conda was never the source of the binary you were seeing. ## Step 5: Remove packages that pip installed inside the environment Some bioinformatics packages are Python libraries that were installed with pip after the environment was created. `conda list` flags these with `pypi` in the channel column, and `conda remove` will refuse or behave unpredictably with them. Remove them with pip, scoped to the same environment: ```bash conda run -n rnaseq pip list conda run -n rnaseq pip uninstall somepackage -y ``` If pip reports it cannot uninstall a package because it was installed by conda, stop and go back to `conda remove`. Mixing the two managers is one of the most common causes of broken environments, covered in the mistakes section below. ## Step 6: Delete an entire environment When an analysis is finished, deleting the whole environment is cleaner than peeling off packages one by one: ```bash conda remove -n rnaseq --all -y ``` or the equivalent: ```bash conda env remove -n rnaseq ``` Verify with: ```bash conda env list ``` The environment should no longer appear. Then check the filesystem directly, another routine Linux command for bioinformatics work: ```bash ls ~/miniconda3/envs/ ``` If a directory with the old environment name survives (this happens occasionally when a removal is interrupted), delete it by hand and then run the cleanup step below to reconcile the package cache. ## Step 7: Reclaim disk space with conda clean Uninstalling packages does not, by itself, free space. Downloaded archives and extracted files in the package cache stay on disk until you clean them: ```bash du -sh ~/miniconda3/pkgs conda clean --all --dry-run conda clean --all -y ``` `-all` removes cached tarballs, unused cached packages that no environment links to, index caches, logfiles, and temporary files. The `-dry-run` first shows what will be deleted and how much space each category uses, which is useful on shared servers where other users may have accounts under the same Conda installation. Run `du -sh` again afterward to confirm the reduction. You now have the complete lifecycle. Here is a quick reference table: | Goal | Command | Notes | |--|--|--| | List all environments | `conda env list` | Asterisk marks active environment | | List packages in an environment | `conda list -n rnaseq` | Add a package name to filter | | Preview removal | `conda remove -n rnaseq samtools, dry-run` | Read the REMOVED and DOWNGRADED sections carefully | | Remove one package | `conda remove -n rnaseq samtools -y` | Dependencies are removed only if unused | | Remove several packages | `conda remove -n rnaseq cutadapt multiqc -y` | One transaction, one solve | | Remove a package by environment path | `conda remove -p /full/path/to/env samtools -y` | Use when the environment is not registered by name | | Delete an environment | `conda remove -n rnaseq, all -y` | Cannot target the active environment | | Back up before removal | `conda env export -n rnaseq > backup.yml` | Keep this file, it is your rollback record | | Roll back a transaction | `conda install -n rnaseq, revision 3` | See Step 8 | | Free disk space | `conda clean, all -y` | Do a `-dry-run` first | ## Step 8: Roll back a removal with revisions Conda records every transaction as a numbered revision. If you removed a package and a pipeline broke, list the history: ```bash conda list -n rnaseq --revisions ``` Expected output (abbreviated): ``` 2024-03-14 10:22:31 rev 3 removed samtools, htslib 2024-03-01 09:15:02 rev 2 installed multiqc, cutadapt ``` Then restore the state before the removal: ```bash conda install -n rnaseq --revision 2 -y ``` Rollbacks are reliable for recent changes but are not a substitute for the `environment.yml` export from Step 1, because revision history can be pruned and does not travel with the environment if you move to another machine. ## Common errors with exact messages and fixes **"PackagesNotFoundError: The following packages are missing from the target environment: - samtools"**. You tried to remove a package that is not installed under that name in that environment. Fix: run `conda list -n rnaseq | grep samtools` and use the exact package name, or check whether you named the wrong environment. **"EnvironmentLocationNotFound: Not a conda environment: /home/you/miniconda3/envs/rnaseq2"**. A typo in the environment name. Fix: run `conda env list` and copy the name exactly. **"CondaEnvironmentError: cannot remove current environment. deactivate and run conda remove again"**. You tried to delete the environment you are currently inside. Fix: run `conda deactivate` (repeat if your prompt still shows the environment name) and rerun the command. **"RemoveError: 'requests' is a dependency of conda and cannot be removed from conda's operating environment"**. You tried to remove a package from the `base` environment that Conda itself needs to run. Fix: never install analysis tools in base. Create a project environment with `conda create -n myproject` and work there. **The solver proposes removing or downgrading 40 packages when you asked to remove one.** A widely used package such as a Python interpreter or a compression library is being reorganized to satisfy remaining dependencies. Fix: read the dry-run output, and if the cascade looks wrong, delete the environment and rebuild it from your exported YAML instead of fighting the solver. **A removal hangs on "Solving environment" for many minutes.** The classic solver struggles with large environments. Fix: install `mamba` in base and use `mamba remove`, which uses a faster solver for the same operation. ## Common Mistakes and Limitations These are the errors that cause real damage in bioinformatics workflows, gathered from the ways environments actually break. 1. **Installing tools in base and then trying to clean base.** Base must stay lean because Conda runs from it. If `conda remove` refuses with a RemoveError naming a dependency of conda, that is the system protecting itself. Create per-project environments instead. 2. **Deleting an environment directory with `rm -rf` instead of `conda env remove`.** Manually deleting `~/miniconda3/envs/old_env` usually works, but it leaves extracted package files in the shared `pkgs/` cache unaccounted for, and any running process with open file handles in that directory will keep them. Use the proper command, then clean the cache. 3. **Assuming `conda remove` uninstalls dependencies.** It removes a dependency only if no other package in that environment needs it. If you installed `samtools` and want `htslib` gone too, name both explicitly or check the dry-run output to see whether `htslib` is included in the removal plan. 4. **Using `conda remove` on pip-installed packages.** Packages installed with pip after environment creation are invisible to Conda's dependency graph. Conda may appear to succeed while the pip copy remains, or it may error. Use `conda run -n ENV pip uninstall` for those. 5. **Not exporting the environment before removal.** Without `conda env export`, reconstructing the exact working version set later may be impossible, particularly for tools whose Bioconda builds move quickly. This single habit prevents most uninstall-related regret. 6. **Removing a package that an active pipeline is using.** Long-running jobs, snakemake rules, and Jupyter kernels hold file handles into the environment. Deleting files underneath a running job can produce confusing "file not found" errors mid-analysis, not at install time. Finish or stop the job first. 7. **Trying to uninstall conda itself with `conda remove conda`.** Conda cannot remove itself. To uninstall Conda from a Linux workstation, delete the installation directory (for example `rm -rf ~/miniconda3`) and remove the `conda initialize` block from your `~/.bashrc`, then open a new shell. 8. **Blaming Conda for space that the cache holds.** Users frequently uninstall packages, see no change in disk usage, and conclude removal failed. The space lives in `pkgs/` until `conda clean` runs. 9. **Expecting channel-level cleanup.** Uninstalling a package does not remove the Bioconda or conda-forge channel configuration. If you added channels with `conda config, add channels` for one tool, those channels keep influencing every future solve. Review them with `conda config, show channels`. One limitation to state plainly: command syntax and solver behavior differ between conda versions and between conda and mamba, so always confirm the flags with `conda remove, help` on your own installation before scripting bulk removals. ## When to uninstall less and containerize more Modern bioinformatics increasingly avoids the uninstall problem altogether by running tools in containers, where disposal means deleting a container rather than surgically editing an environment. The nf-core framework, a collection of community-curated analysis pipelines, was designed specifically so that software dependencies are portable and reproducible across institutions rather than coupled to one workstation's environment [8]. Tools such as CREDO generate Docker images that embed Bioconductor and Conda environments, so package definitions live in a versioned Dockerfile rather than in a mutable local installation [9]. Prebuilt images such as Dugong bundle thousands of bioinformatics tools in a single reproducible Ubuntu-based image [10], the COMBAT-TB Workbench ships a complete tuberculosis analysis platform as a single Docker application [11], and the BioContainers project distributes thousands of bioinformatics tools as Conda, Docker, and Singularity packages with a searchable registry [12], building on registry infrastructure such as BioShaDock that curates bioinformatics-specific images [13]. The practical takeaway: if a tool will be used once, or if your environment has drifted into a state you cannot reason about, pulling a container (or rebuilding a fresh environment from an exported YAML) is often cheaper than a careful uninstall. If the environment is actively used and you only need to drop one tool, the steps above are the right approach. A historical comparison makes the value concrete. Installing a local BLAST used to mean obtaining the software, matching it to your hardware and operating system, and manually building searchable sequence databases, as described in early protocols for local BLAST deployment [14]. Conda reduced that to a single install command, and the removal commands in this guide reduce teardown to a few minutes. That symmetry, cheap install and cheap removal, is what lets you experiment freely on a workstation without leaving wreckage behind. ## What Conda Actually Touches When You Remove a Package: The conda-meta Directory Most guides stop at `conda remove`, but understanding what Conda changes on disk makes every error message easier to interpret. Each environment keeps a manifest directory called `conda-meta`. Inside it, every installed package has a JSON file whose name encodes the package, version, and build string: ```bash ls ~/miniconda3/envs/rnaseq/conda-meta/ | grep samtools ``` Expected output: ``` samtools-1.19.2-h50ea8bc_0.json htslib-1.19.1-h81da01d_2.json ``` Each of these JSON files records the package's dependencies, the channel it came from, and, importantly, a complete list of every file the package placed in the environment. When you run `conda remove`, Conda reads that file list and deletes exactly those paths, then rewrites the environment's history entry. This is why removal is generally precise: Conda does not guess which files belong to a package, it consults a manifest it wrote at install time. You can inspect a manifest yourself, which is useful when a file seems to survive a removal or when you want to know what a package dropped onto your PATH: ```bash cat ~/miniconda3/envs/rnaseq/conda-meta/samtools-1.19.2-h50ea8bc_0.json | less ``` Look for the `files` key. It lists paths such as `bin/samtools` and `share/man/man1/samtools.1` relative to the environment root. Two practical uses follow from this: 1. **Finding the source of a mystery binary.** If a tool with the same name exists in two environments, searching each `conda-meta` directory tells you which package delivered it, so you remove the right one. 2. **Diagnosing half-finished transactions.** If a removal was interrupted, a JSON manifest may exist for a package whose files are gone, or files may exist with no manifest. The safest recovery in either case is to rebuild the environment from an export rather than to hand-edit `conda-meta`. The environment directory also contains a `history` file, a plain-text log of every transaction Conda has performed there. This is the file behind the revision list shown in Step 8 of the main guide. If revisions ever look inconsistent or missing, inspect the history file directly: ```bash less ~/miniconda3/envs/rnaseq/conda-meta/history ``` One caution applies to all of this: treat `conda-meta` as read-only. Editing or deleting manifests by hand produces an environment that `conda list` reports incorrectly, and the solver will then make decisions based on false information. If an environment is corrupted badly enough that you are tempted to edit manifests, that is the signal to rebuild instead. ## A Complete Worked Example: Slimming Down a Two-Year-Old RNA-seq Environment ![Decision path that starts from a dry run and ends either in a single conda remove or in exporting and rebuilding the environment.](/article-images/illustrations/uninstall-conda-package-bioinformatics-removal-triage.webp) The following end-to-end scenario shows how the individual steps combine in practice, including the decision point where removal stops being the right tool. The names are illustrative but every command is real. Suppose you inherit an environment called `aging_rnaseq` built over two years of projects. It contains three aligners, four QC suites, two counting tools, and a scatter of packages installed ad hoc during tutorials. Disk usage checks are starting to matter and a collaborator asks why the environment takes minutes to solve. **Survey.** Start with the inventory and a size estimate: ```bash conda env list conda list -n aging_rnaseq | wc -l du -sh ~/miniconda3/envs/aging_rnaseq ``` The `wc -l` count tells you how large the package roster is; the `du` figure is a rough size, with the hard-link caveat discussed in the cache section below. **Export the insurance policy.** Before anything else: ```bash conda env export -n aging_rnaseq > aging_rnaseq_backup.yml conda env export -n aging_rnaseq -explicit > aging_rnaseq_explicit.txt ``` The second export is a build-level record including channel URLs and build hashes, which is the strongest reconstruction record you can keep and doubles as documentation in settings where software changes must be auditable [7]. **Target a removal with a dry run.** Suppose Trimmomatic was used on one old project and nothing else: ```bash conda remove -n aging_rnaseq trimmomatic -dry-run ``` Read the plan. If the REMOVED section lists only `trimmomatic` and perhaps a Java runtime that nothing else uses, the removal is cheap and safe. Proceed: ```bash conda remove -n aging_rnaseq trimmomatic -y ``` **Hit the cascade.** Next you try to retire an old aligner: ```bash conda remove -n aging_rnaseq hisat2 -dry-run ``` The dry run reports that removing `hisat2` will also downgrade a shared Python build because an old QC package pinned to it. This is the decision point. Fighting a solver over shared interpreters rarely ends well. The better move is the rebuild path described in its own section below: export to YAML, prune the YAML, create a fresh environment, run your pipelines once against it, and only then delete the old environment wholesale. **Verify and finish.** After each accepted removal, run both verification commands from Step 4 of the main guide: the `conda list` check and the `conda run` executable check. When the environment is finally retired: ```bash conda remove -n aging_rnaseq -all -y conda clean -all -dry-run conda clean -all -y ``` The lesson from the scenario: individual `conda remove` calls are excellent for leaf packages, tools nothing else depends on, and become expensive rapidly when the target sits in the middle of a dependency web. Knowing which kind of package you are holding, which the dry run reveals in seconds, is what separates a five-minute cleanup from an afternoon of solver battles. ## The Package Cache in Depth: Hard Links, Orphans, and Targeted Cleaning The main guide explains that `pkgs/` holds cached archives. Three additional details change how you measure and clean it. **Hard links mean size numbers lie a little.** Conda links files from `pkgs/` into environments rather than copying them, so a single physical file may appear under two paths. `du` on an environment directory reports the apparent size including linked content, which can make an environment look larger than its exclusive contribution to disk usage. When comparing environment sizes on a shared server, look at trends rather than absolutes, and always compare before-and-after numbers using the same command. **Cleaning has categories, and they differ in risk.** Instead of jumping straight to the everything option, you can run each category separately and see its footprint: ```bash conda clean -tarballs -dry-run conda clean -packages -dry-run conda clean -index-cache -dry-run conda clean -tempfiles -dry-run ``` Cached tarballs, the compressed archives downloaded during installs, are the safest to delete and often the largest contributors, because an archive is kept even after its extracted form is in place. Cached packages are the extracted directories not currently linked by any environment; removing them is safe for running work but means the next environment creation re-downloads. The index cache is metadata about channels and rebuilds automatically. On a multi-user installation, coordinate before cleaning: everyone whose environments link into that cache shares it, so cleaning helps everyone's next solve but removes everyone's warm download cache. **Orphan detection is conservative.** After removing a package from an environment, its cached copy in `pkgs/` may still be referenced by another environment, in which case cleaning will correctly keep it. If no environment references it, `conda clean -packages` collects it. Running `conda clean` after every round of removals is the rhythm that keeps the cache proportional to what you actually use. A final check that ties this to ordinary Linux commands for bioinformatics work: to see which of your environments consume the most space, ranked: ```bash du -h ~/miniconda3/envs | sort -rh | head -20 ``` ## Removing pip-Installed and Mixed-Install Packages Without Breaking Environments The main guide covers the basic pip case. Three extensions matter in real projects. **Back up the pip side too.** `conda env export` records pip-installed packages under a `pip` section, but if you are about to remove pip packages surgically, capture the current state first: ```bash conda run -n rnaseq pip list > rnaseq_pip_backup.txt ``` **pip does not remove dependencies.** When you `pip uninstall` a Python library, pip removes only that distribution, never the packages it depended on. This contrasts with conda, whose transaction may drop now-unused dependencies. The practical consequence: removing several pip packages one after another tends to leave a growing set of orphaned Python libraries behind. If orphans accumulate, note their names from your backup file and remove the ones nothing else imports, or accept them as harmless overhead. **The R and Bioconductor parallel.** The same mixed-manager problem exists for R environments inside Conda. If an environment includes R and you later added Bioconductor packages through BiocManager, those packages live inside the environment's R library tree but are invisible to `conda remove`. They are removed from inside R with `remove.packages()`. The rule generalizes: whoever installed a package is the manager that can cleanly remove it. If you did not install it and cannot tell, check the manager's own inventory first, `conda list`, then `pip list`, then inside R `installed.packages()`, before attempting any removal. **Watch for editable installs.** Development installs created with pip's editable mode point back at a source directory rather than containing compiled files. Uninstalling them with pip removes the link, not the source tree, so confirm whether you still need the source before deleting anything. This comes up when bioinformaticians prototype a script as an editable package, then productionize it from Bioconda later; at that point the editable install should be removed to avoid shadowing the Conda-installed command. ## Comparing Removal Tools: conda remove, mamba remove, pip uninstall, and rm -rf ![Comparison of conda remove, mamba remove, pip uninstall, conda env remove and rm -rf across dependency handling and pip packages.](/article-images/illustrations/uninstall-conda-package-bioinformatics-removal-tools.webp) Choosing the right removal tool matters as much as choosing the right install tool. This comparison makes the boundaries explicit. | Tool | What it removes | Dependency handling | Safe for pip packages | Notes | |-|-|-|-|- | `conda remove` | Conda-tracked packages from one environment | Drops now-unused dependencies within the same transaction | No | Dry run available; uses the classic solver | | `mamba remove` | Same as conda remove | Same transaction semantics | No | Much faster solving on large environments | | `pip uninstall` | pip-installed Python distributions | Never removes dependencies | Not applicable | Scope it through `conda run -n ENV` | | `conda env remove` | An entire environment | Removes everything together, no solving | Removes pip packages too because it deletes the whole tree | The blunt but clean instrument | | `rm -rf` on the env directory | The directory tree only | None | Yes, but leaves cache entries unaccounted for | Last resort; follow with cache cleanup | The pattern to internalize: removal tooling should match installation tooling per package, and whole-environment deletion is the one operation that cleans everything at once because it removes the filesystem tree rather than consulting manifests. That is also why whole-environment deletion is safe even for pip packages, while per-package deletion through the wrong manager is the classic path to a broken environment. The mamba entry deserves one clarification, because it trips people up: `mamba remove` does not maintain a separate package database or remove things differently. It performs the same transaction type against the same environments, with a faster solver. A dry run through mamba and a dry run through conda for the same request should describe the same plan; if they differ, one of the two is reading a different configuration or channel state, which is worth investigating rather than ignoring. ## Uninstalling on Shared HPC Systems: Permissions, Etiquette, and Where Your Environments Really Live Cluster environments add constraints that a laptop does not have. **Find out where your environments actually are.** On many clusters, the Conda installation is shared under a path such as `/opt` or a software scratch area, while your environments live in your home or scratch directory. Confirm with: ```bash conda info ``` The `envs directories` and `package cache` entries tell you which directories your environments use and, critically, whether the package cache is shared beyond your account. If the cache is shared, `conda clean` on it affects other users, so check local policy or ask an administrator before running it there. **Permission errors during removal.** If `conda remove` fails with permission denied messages, you are probably removing from an environment or cache that your account does not own. This happens when environments were created under a service account, or when an administrator installed software system-wide. The fix is organizational, not technical: have the owner perform the removal, or rebuild the environment under your own account with your own export file and remove the shared one through the proper request process. **Open file handles on long-running jobs.** Before removing packages or environments on a cluster, check whether any of your processes still use them. The classic check pairs `lsof` with `grep`: ```bash lsof + ~/miniconda3/envs/rnaseq 2>/dev/null | head ``` If a running Snakemake job, Jupyter kernel, or long queue job holds files in that environment, finish or stop it first. Deleting files underneath a running process produces failures at arbitrary later points in the analysis, which are far harder to debug than a refusal at uninstall time. **Quota crunches.** A common trigger for uninstall campaigns is a home directory quota warning before a large download or a big run. The highest-yield sequence is usually: delete whole environments for finished projects first, then clean the cache, then prune individual packages last, because per-package removals free the least space per unit of effort. Check your quota system's own reporting tool alongside `df -h` on the relevant filesystem to see whether your reclaim attempts actually moved the number. ## Rebuilding Instead of Removing: The YAML Prune Workflow When an environment has drifted, deleting packages one at a time is often the slowest path to a clean state. The rebuild workflow is faster and produces a better artifact. **Step A. Export and prune.** Start from the backup you made earlier: ```bash conda env export -n aging_rnaseq > aging_rnaseq.yml ``` Edit the YAML. Remove dependencies you no longer want, and remove pip entries that were experiments. A useful discipline: if you cannot say why a package is in the file, delete it from the file. The resulting document is not just an install recipe, it is the environment's bill of materials, which is exactly what reproducibility-minded workflows want to preserve. **Step B. Create the fresh environment.** ```bash conda env create -n rnaseq_clean -f aging_rnaseq.yml ``` **Step C. Compare before deleting anything.** Produce exports of both environments and diff them, a pattern that reuses everyday Linux text tools: ```bash conda env export -n rnaseq_clean > rnaseq_clean.yml diff aging_rnaseq_backup.yml rnaseq_clean.yml | less ``` The diff shows exactly what changed between the old and new environments. Anything you removed intentionally should appear here; anything else that changed deserves a second look before you retire the original. **Step D. Parallel-run critical tools.** Before deleting the old environment, run a representative task with the key tools in the new one and compare outputs. For an alignment step, compare summary metrics; for QC, compare report contents. Only after the new environment passes should you delete the old one with `conda remove -n aging_rnaseq -all -y` and clean the cache. This workflow has a second benefit the per-package approach cannot offer: the new environment is defined by a file you can commit to version control, share with a collaborator, or attach to a manuscript's methods description. The Galaxy and Bioconda packaging tutorial makes the same point from the curation side, that controlled updates and retirements of software are part of maintaining analysis infrastructure, not an afterthought. ## Verifying an Environment After Removal: Diffs, Revisions, and Smoke Tests Removal is not done when the command returns; it is done when you have evidence the environment still works. Three layers of verification, in increasing strength. **Inventory diff.** You exported the environment before touching it. Export again and diff: ```bash conda env export -n rnaseq > rnaseq_after.yml diff rnaseq_backup.yml rnaseq_after.yml ``` The diff should contain exactly the packages you intended to remove and nothing else. Unexpected lines are the earliest warning that a transaction did more than you expected. **Revision cross-check.** `conda list -n rnaseq -revisions` shows the transaction history. Confirm the most recent revision matches what you intended, in both direction and package set. **Smoke tests.** Run each surviving tool that shares libraries with the removed package. For example, if you removed `htslib` alongside `samtools` but kept a variant caller that links against compression libraries, run that caller on a small test file. A tool that imports or links successfully at startup is the strongest practical signal that the removal did not clip a shared library it needed. Build a tiny test dataset into your project's repository so this check takes seconds rather than minutes, which makes it likely to actually happen. For environments used in regulated or manufacturing-adjacent settings, record the verification outputs alongside the export files, since the documentation trail of exact versions and the evidence that they were preserved is part of the audit story [7]. ## Linux Housekeeping Commands That Pair Well with Conda Maintenance Because this workflow lives in a terminal, a short toolkit of standard Linux commands for bioinformatics work makes every step faster. These complement, not replace, the Conda commands in the main guide. **Measuring before and after.** ```bash df -h ~ du -sh ~/miniconda3/pkgs ~/miniconda3/envs/* ``` `df` shows filesystem-level free space, which is the number your quota or backup system cares about. `du` shows per-directory consumption. Running the pair before and after cleanup is the honest way to confirm that your work reclaimed real space. **Finding what is big inside an environment.** ```bash du -h ~/miniconda3/envs/rnaseq | sort -rh | head -15 ``` This often reveals that a few large libraries dominate an environment, which reframes uninstall decisions: removing three small utilities saves less than identifying one heavyweight dependency you can retire with the tool that needs it. **Filtering package inventories.** The `grep` pipeline from the main guide scales up: ```bash conda list -n rnaseq | grep -i -E "align|trim|qc" ``` **Checking what still uses an environment.** Beyond `lsof`, a quick `ps` scan finds processes whose command lines name the environment: ```bash ps aux | grep -i rnaseq | grep -v grep ``` **Interactive disk exploration.** If your system has `ncdu`, it gives a navigable view of where space goes inside `pkgs/` and `envs/`, which is faster than repeated `du` calls when you are hunting a few gigabytes on a shared volume. None of these tools know anything about Conda's linking model, so treat their numbers as evidence to interpret, not as ground truth about how much space a removal will free. ## Common Misconceptions About Uninstalling Conda Packages Several beliefs circulate that lead to wasted time or broken environments. Each is stated with the correction. **Misconception: removing a package frees its disk space immediately.** As the main guide notes, the cache holds onto archives. Add the hard-link subtlety: even after `conda clean`, the space reclaimed equals only the portions not shared with surviving environments. The reliable sequence is remove, clean, then re-measure with `du`. **Misconception: conda has an autoremove command that clears all orphans.** It does not. Unused dependencies are dropped only within the transaction that removes their dependent. Packages orphaned across multiple separate transactions can accumulate. If orphan buildup matters to you, either remove related packages in a single transaction or verify the dry-run output each time. **Misconception: removing a package in one environment affects other environments.** Environments are isolated. A removal in one environment cannot delete files from another, because each environment's files are linked independently. The only cross-environment effect is on the shared cache, and cleaning the cache never removes files that a surviving environment still links. **Misconception: mamba and conda keep separate package lists.** They operate on the same environments and the same manifests. Mixing them for install and removal is safe and common. **Misconception: pip uninstall inside one environment affects other environments.** pip operates only on the Python environment it is invoked against, which is why scoping it through `conda run -n ENV` matters. A bare `pip` on your PATH may belong to a different environment entirely, which is a frequent source of "I uninstalled it but it is still there" reports. **Misconception: deleting the environment directory removes its cache entries.** The reverse of the main cleanup lesson. Manual deletion leaves the cache untouched, which is why `rm -rf` followed by nothing makes disk usage worse over time, not better. **Misconception: a successful `conda remove` means the binary is gone from your shell.** As the main guide's verification step shows, a binary of the same name may exist elsewhere on your PATH from an older manual install. The `command -v` check is the arbiter. ## Practical Scenarios: When Uninstalling Pays Off in Real Projects **Scenario 1: A reviewer asks which version produced a figure.** Months after a paper submission, you need the exact aligner version behind a key result. If the environment was pruned carelessly, you may only know the tool was "recent at the time." If you followed the export-before-removal habit, you produce the YAML, and reconstructing the exact environment takes one command. This is the reproducibility argument in miniature, and it costs one file per environment. **Scenario 2: A quota crunch before a large download.** A new reference genome and its indices will not fit. The ranked cleanup order from the HPC section applies: finished-project environments first, cache second, targeted package removals last. In ten minutes a badly cluttered account typically recovers enough space without touching active work. **Scenario 3: Handing a project to a collaborator.** Instead of telling them to "install samtools and something for QC," you hand over the pruned YAML from the rebuild workflow. Their `conda env create -f` reproduces your working set, and your own old cluttered environment becomes safe to delete because the definition, not the directory, now carries the knowledge. Tools distributed through Bioconda, from the FASTA and assembly utility collection [2] to the spectrum_utils plotting library [3], the ipcoal coalescent simulator [4], and capC-MAP for Capture-C analysis [5], all reinstall cleanly from a YAML that names them, which is the property that makes the handoff reliable. **Scenario 4: Jupyter-based teaching or analysis servers.** Before deleting any environment on a shared notebook server, list the registered kernels and remove the ones that pointed at retired environments, since a dead kernel spec shows up as a broken option for every user of the server [6]: ```bash jupyter kernelspec list jupyter kernelspec uninstall old_rnaseq_kernel ``` ## Containers as the Uninstall Escape Hatch: Operational Details The main guide makes the strategic case for containers. Operationally, container workflows change what "uninstall" means in concrete ways worth knowing. A pipeline framework such as nf-core resolves software into containers at run time, so your workstation keeps no per-tool environments to clean at all; the software lifecycle moves to images that are pulled, used, and discarded, and reproducibility is anchored in the pipeline definition rather than in any machine's local state [8]. The BioContainers project supplies that layer for thousands of tools, distributable as Conda, Docker, and Singularity packages with a searchable registry, so for many tools the decision is between an environment edit and a one-line pull [12]. Prebuilt all-in-one images such as Dugong [10], platform images such as the COMBAT-TB Workbench [11], curated registries built on BioShaDock [13], and Docker images that embed Bioconductor and Conda definitions in a versioned file [9] all shift package management from your home directory into a Dockerfile you can diff and revert like any other text file. That shift changes cleanup in two directions. First, disposal becomes coarse but trivial: an unused image is one command away from deletion, and container runtimes keep their own caches that also need periodic cleaning, so the habits transfer even though the commands differ. Second, it makes the remaining Conda environments smaller and more deliberate, because one-off tools stop entering them. A reasonable policy for a workstation: keep environments only for tools you invoke interactively and frequently, route pipeline execution through containers, and revisit environment contents whenever an export diff grows longer than a screen. The historical framing from the main guide still applies: local BLAST once demanded manual installation, hardware matching, and database construction by hand [14]. Containerized pipelines extend the same simplification to teardown, which is why the uninstall skills in this guide are best understood as the maintenance half of a system where most heavyweight software never becomes permanent in the first place. ## A Pre-Removal and Post-Removal Checklist For quick reference, the entire workflow compressed into an ordered checklist you can keep beside your terminal. Before removing: 1. Run `conda env list` and confirm the target environment name character for character. 2. Run `conda list -n ENV | grep PACKAGE` and confirm the exact package name and channel. 3. Export the environment to YAML, and for high-stakes cases also with the explicit format. 4. Run the removal with a dry run and read the REMOVED, DOWNGRADED, and UPDATED sections. 5. Check for running jobs, kernels, or sessions holding the environment open. Remove: 6. Execute `conda remove -n ENV PACKAGE -y`, or `mamba remove` for large environments. After removing: 7. Confirm with `conda list -n ENV PACKAGE` that the inventory entry is gone. 8. Confirm with `conda run -n ENV PACKAGE -version` that the executable is gone. 9. Diff the post-removal export against the backup. 10. Clean the cache, first with a dry run, then for real, and re-measure with `du`. 11. For pip-installed packages found later, use the pip path scoped through `conda run`. Printed and followed in order, this checklist turns package uninstalling from an act of hope into a documented, reversible, and verifiable operation, which is the standard everything else in a bioinformatics workflow is held to. ## Frequently Asked Questions ### Does conda remove also delete the package's dependencies? Only if no other package in that environment needs them. Run the removal with `-dry-run` first to see the exact list Conda intends to remove, downgrade, or update. ### What is the difference between conda remove and conda env remove? `conda remove` deletes specific packages from an environment, while `conda env remove` (or `conda remove -n NAME, all`) deletes the entire environment including all of its packages. ### Can I undo a conda remove? Yes, if the transaction was recent. Run `conda list -n ENV, revisions` to find the revision number before your removal, then `conda install -n ENV, revision N` to restore that state. ### Why is my disk still full after uninstalling packages? Conda keeps downloaded and extracted package archives in the shared `pkgs/` cache so environments can share files. Run `conda clean, all -y` after uninstalling to reclaim that space. ### How do I remove a package that pip installed inside a conda environment? Use `conda run -n ENV pip uninstall PACKAGE -y`. Conda does not track pip-installed packages in its dependency graph, so `conda remove` cannot manage them. ### Is it safe to remove packages from the base environment? No. The base environment contains conda itself and its dependencies, and removing them produces a RemoveError or breaks the conda command. Create separate project environments for your tools. ### How do I uninstall conda itself from Linux? Delete the installation directory (for example `rm -rf ~/miniconda3`) and remove the conda initialize block from your `~/.bashrc`, then open a new shell. Conda cannot remove itself. ### Should I uninstall old packages one by one or rebuild the environment? If you need to remove a handful of related packages, use `conda remove` with a dry run. If an environment is cluttered or conflicted, export it to YAML, prune the file, and build a fresh environment, which is faster and more reproducible. ## Sources 1. [Bioconda: sustainable and comprehensive software distribution for the life sciences](https://pubmed.ncbi.nlm.nih.gov/29967506/) 2. [bit: a multipurpose collection of bioinformatics tools](https://doi.org/10.12688/f1000research.79530.1) 3. [spectrum_utils: A Python package for mass spectrometry data processing and visualization](https://pubmed.ncbi.nlm.nih.gov/31809021/) 4. [ipcoal: an interactive Python package for simulating and analyzing genealogies and sequences on a species tree or network.](https://pubmed.ncbi.nlm.nih.gov/32399564/) 5. [capC-MAP: software for analysis of Capture-C data](https://pubmed.ncbi.nlm.nih.gov/31173058/) 6. [Abstract 2073: Genomics to Notebook (g2nb): Extending the electronic notebook to address the needs of cancer bioinformatics](https://doi.org/10.1158/1538-7445.am2023-2073) 7. [Moving analytical ultracentrifugation software to a good manufacturing practices (GMP) environment.](https://pubmed.ncbi.nlm.nih.gov/32559250/) 8. [The nf-core framework for community-curated bioinformatics pipelines](https://pubmed.ncbi.nlm.nih.gov/32055031/) 9. [CREDO: a friendly Customizable, REproducible, DOcker file generator for bioinformatics applications](https://pubmed.ncbi.nlm.nih.gov/38475691/) 10. [Dugong: a Docker image, based on Ubuntu Linux, focused on reproducibility and replicability for bioinformatics analyses.](https://pubmed.ncbi.nlm.nih.gov/28968637/) 11. [The COMBAT-TB Workbench: Making Powerful Mycobacterium tuberculosis Bioinformatics Accessible.](https://pubmed.ncbi.nlm.nih.gov/35138128/) 12. [BioContainers Registry: searching bioinformatics and proteomics tools, packages, and containers](https://pubmed.ncbi.nlm.nih.gov/33625229/) 13. [BioShaDock: a community driven bioinformatics shared Docker-based tools registry.](https://pubmed.ncbi.nlm.nih.gov/26913191/) 14. [Installing, maintaining, and using a local copy of BLAST for intranet and workstation use.](https://pubmed.ncbi.nlm.nih.gov/18428721/)