How to Change Python Version in an Existing Conda Environment

A Python 3.12 request with `–dry-run` leaves me curious about the plan for the project environment. Naming the target environment makes the intended change explicit, which I find useful.

Your first question is how the requested Python line fits the packages already in the environment. Read the proposed transaction to see what Conda would change before you apply it.

What changes when you change Python in a Conda environment?

Conda installs Python as a package inside each environment. When you request a different minor version, its solver checks whether the other installed packages still fit and may add, remove, or replace packages to reach a compatible set. The Conda Python guide describes the same package-based model.

A version change is a package transaction, not a pointer switch to another system interpreter. Conda’s install command can target a named environment, and a dry run shows the proposed transaction before applying it.

An activated terminal puts the environment name in the prompt, as this screenshot shows. The steps below use an explicit environment name instead, so they do not depend on which prompt is active.

If you are choosing between Conda and pip for package management, see our Conda vs pip comparison.

Before changing the version

Choose the Python minor version your project requires, then identify the exact Conda environment that runs it. The examples use project as the environment name, so replace it with yours.

If Conda is not installed yet, our Anaconda setup tutorial covers that separate task. Before changing an existing environment, check these details:

Use the environment list to copy the name exactly, then inspect its Python history before changing packages:

conda env list
conda list --name project --revisions

Save the revision number before changing the environment because it identifies the Conda package state you can restore, not your project files.

Change Python in an existing Conda environment

Even when the shell has another environment active, include the target name in each command to keep the transaction on the project you chose. This avoids changing a different environment.

1. Check the environment’s Python version

Ask Conda to run Python by environment name, so the result cannot come from whichever interpreter the shell finds.

conda run --name project python --version

2. Preview the Python version change

Conda calculates a transaction but does not apply it when you include –dry-run. Add that option to the version request first.

conda install --name project python=3.12 --dry-run

I ran the downgrade on Linux ARM. Conda moved the test environment from Python 3.13.15 to 3.12.14, removed the Python 3.13 ABI package, added libnsl and libxcrypt, and revised pip.

Your plan can differ because Conda resolves against your platform, channels, and installed package constraints.

Read the full plan before moving on. If it removes a package your project needs or reports an unsatisfiable set, stop here and resolve that constraint instead of skipping dependency checks.

3. Apply the reviewed plan

When the proposed changes fit the project, run the same request without the dry-run option. Conda displays the transaction again and asks you to confirm it.

conda install --name project python=3.12

Because confirmation applies to every package in the transaction, enter yes only if the displayed plan still matches the one you reviewed. Conda may revise pip or other packages along with Python.

4. Verify the selected interpreter

The named-environment check reported Python 3.12.14 after the transaction.

conda run --name project python --version

Python’s version output identifies the selected interpreter, so run the project’s tests or import checks to find whether its dependencies still work.

When Conda cannot solve the requested version

The dry run leaves the environment unchanged, so use the solver’s error and package plan to narrow the cause. An unsatisfiable error means Conda found no compatible package set.

• No matching build: the configured channel may not have that Python version for your platform. Check the project’s supported Python versions and the channel that supplies its packages.
• Conflicting dependency: an installed package may require a different Python line. Review which package pins appear in the solver error, then choose a compatible set rather than bypassing dependency checks.
• Wrong prompt: Conda commands belong in a terminal or Anaconda Prompt, not at the Python interactive prompt. Pasting a Conda command there produces a Python SyntaxError.

In my Linux ARM test, I tried changing Python inside a Conda clone, and its exact package specs blocked Python 3.12. The copied libffi build was incompatible.

Because the clone could not solve the version change, I chose to record a revision and preview the request directly against the named environment.

Keep a rollback path for the environment

If the Python change breaks the project, use the saved revision number to restore Conda’s recorded package transaction.

conda install --name project --revision 0
conda run --name project python --version

In my test, restoring revision 0 returned the environment to Python 3.13.15 before I applied the Python 3.12 request again. Replace 0 with your saved revision number.

Because a Conda revision restores only Conda-managed packages, keep the old environment state until your project’s tests pass under the new Python version.

Frequently asked questions

The environment name scopes the change, while the Python version spec leaves the patch build to Conda’s solver.