If you manage your Python development environment with conda, it is worth reading the article below first.

* **Recommended reading:**
  
- [Getting Started with Anaconda, Miniconda, and the World of Conda](/en/whitedec/2025/4/25/intro-to-conda-anaconda-miniconda/)


This article briefly reviews those basics and focuses on **how to create, delete, clone, and migrate conda environments in practice**.

## Anaconda vs. Miniconda in a Nutshell {#sec-2acd9c6793ed}

In short, the difference looks like this:

* **Anaconda**:
  An **all-in-one distribution** that installs many commonly used data science and machine learning packages at once.
* **Miniconda**:
  A **minimal distribution** that provides only conda’s environment and package management features, leaving you to install the packages you actually need.

I personally prefer to **start light and add packages only when necessary**, so I generally recommend installing **Miniconda and building environments on top of it**.

Its advantages include:

* Lower disk usage
* Less update overhead
* Cleaner environments, since you install only what each project actually needs

## A Quick Overview of conda Environments {#sec-205d2419d2cb}

A conda **environment** is, simply put, an isolated set of Python and packages for a specific project.

* `env A`: Python 3.10 + Django 4 + specific library versions
* `env B`: Python 3.11 + FastAPI + a completely different set of libraries

The point is to **isolate different versions so they do not interfere with one another**.

Here are the basic commands you will use most often when working with environments:

```bash
# Show a list of currently installed conda environments
conda env list

# Or
conda info --envs
```

## Creating a conda Environment {#sec-4f854f72cc93}

### 3.1 Creating the most basic environment {#sec-ce9334298e11}

```bash
conda create -n myenv python=3.12
```

* `-n myenv`: sets the environment name to `myenv`
* `python=3.12`: specifies Python 3.12

After creating the environment:

```bash
conda activate myenv   # Activate the environment
conda deactivate       # Deactivate the environment
```

### 3.2 Installing commonly used packages at creation time {#sec-094ab7174ec7}

```bash
conda create -n myenv python=3.12 numpy pandas matplotlib
```

This creates a new environment and installs those packages from Miniconda’s default channels.

After that, you can continue adding packages as needed:

```bash
conda activate myenv
conda install scikit-learn

# Or
pip install requests
```

## Deleting a conda Environment {#sec-b8c75313ebb7}

It is a good idea to remove environments you no longer use.
(conda environments can take up a fair amount of disk space.)

```bash
# Delete the myenv environment
conda env remove -n myenv
```

To confirm that it was removed:

```bash
conda env list
```

If `myenv` no longer appears in the list, the deletion was successful.

## Cloning a conda Environment {#sec-9196b1f97faa}

Cloning is useful when you want to create **another environment with nearly the same setup but a different name**.

```bash
# Create a cloned environment named new-env based on existing-env
conda create -n new-env --clone existing-env
```

This is commonly used when:

* you want to preserve the existing environment as-is
* while experimenting in a separate copy with the same package versions

After cloning:

```bash
conda activate new-env
```

Then verify that everything works as expected.

## Migrating a conda Environment (export / import) {#sec-0f6c9e49fd83}

If you want to move an environment to another PC or server, the most common method is to **export the environment to a file and then create a new environment from that file**.

### 6.1 Exporting an environment — creating a YAML file {#sec-1416fbd5d42e}

```bash
# Export the myenv environment to an env.yml file
conda env export -n myenv > env.yml
```

This `env.yml` file records:

* the environment name
* the channels in use
* the installed packages and their versions

### 6.2 Exporting only a minimal history-based list {#sec-aee5b92c2004}

If you want to record only the packages you explicitly installed, rather than the full list including dependencies, use:

```bash
conda env export -n myenv --from-history > env-min.yml
```

With this approach, when you recreate the environment elsewhere, conda will resolve the necessary dependencies automatically.

### 6.3 Creating an environment somewhere else {#sec-948844e6ebdb}

To create the environment on another PC, server, or even another location on the same machine:

```bash
conda env create -f env.yml
```

This creates an environment using the name and package versions defined in `env.yml`.

* If `env.yml` contains `name: myenv`, the environment will be created with that name.
* If you want a different name, edit the `name:` field in `env.yml` before running the command.

For example, if you change `name: myenv` to `name: myenv-dev`, then run:

```bash
conda env create -f env.yml
conda activate myenv-dev
```

You will get the same environment configuration under a different name.

## Common conda Workflow Patterns {#sec-abb9a2998736}

When building environments with Miniconda, the following patterns are especially useful.

1. **Use one environment per project**

   * Name environments after projects, such as `proj-a-env` or `proj-b-env`.
   * This makes version management easier and reduces conflicts.

2. **Start with a minimal environment and expand only when needed**

   * Install only `python` and a few basic packages at first.
   * Add more later with `conda install` or `pip install` as development progresses.
     This fits Miniconda’s minimal philosophy very well.

3. **Export important environments regularly**

   * At release time or before deployment:

   ```bash
   conda env export -n proj-a-env --from-history > proj-a-env.yml
   ```

   * If you commit this file to your repository, your team members can easily reproduce the same environment.

4. **Clone before major changes**

   * Before large package upgrades or Python version changes:

   ```bash
   conda create -n proj-a-backup --clone proj-a-env
   ```

   * If something goes wrong, you can quickly return to the backup environment.

![python conda environment image](/media/whitedec/blog_img/python-conda-env-concept.webp "python conda environment image")

## Conclusion: Start Light and Expand as Needed {#sec-c7c76dc19a3c}

In the end, the choice is fairly simple.

* **Anaconda** is for starting with a broad set of potentially useful packages already installed.
* **Miniconda** is for starting small and installing only what you actually need.

Today, different projects often require different Python versions and package combinations. In that kind of situation, **Miniconda plus well-managed conda environments** gives you far more flexibility.

At a minimum, it helps to know how to:

* create environments (`conda create`)
* activate them (`conda activate`)
* delete them (`conda env remove`)
* clone them (`conda create --clone`)
* move them elsewhere (`conda env export` / `conda env create`)

Once you are comfortable with those basics, you will spend much less time worrying about questions like, “What do I need to uninstall and reinstall this time?” whenever you start a new project.

When you begin your next project:

1. **Create a new environment with Miniconda**
2. Install **only the packages you actually need**
3. If you like the setup, export it to `env.yml` and reuse it later with small modifications

Once this pattern becomes familiar, managing conda environments stops feeling like a chore and becomes a **reliable habit that keeps your projects clean and organized**.