> ## Documentation Index
> Fetch the complete documentation index at: https://anaconda.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing solver errors

Although conda's solver is designed to install packages and their dependencies without creating version conflicts, it can still happen. This tutorial will go over possible solver conflict scenarios and ways to fix them. For more information on the package dependencies and the conda solver, see [Dependencies and the solver](/getting-started/working-with-conda/packages/dependencies).

## Direct dependency conflict

Imagine you have an environment that you know will require Python 3.10, but you also want to install `package-a` into that environment. You decide to specify version 2.0 of `package-a`.

The only problem is, `package-a` 2.0 requires Python 3.11 or later (`>=3.11`) and doesn't have any backwards compatibility built into its version requirements.

If you try to install `python` and `package-a` into an environment with these exact requirements:

```sh theme={null}
conda create --name solver-error-environment python=3.10 package-a=2.0
```

You will get an error like the following:

```sh theme={null}
LibMambaUnsatisfiableError: Encountered problems while solving:
  - package package-a-2.0-py311 requires python >=3.11, 
    but none of the providers can be installed
```

This error tells you that `package-a` requires `python` greater than or equal to version 3.11, but something is blocking that version from being installed.

### Solving the version conflict

There are several strategies you can use to resolve a dependency version conflict.

#### Create different environments

The safest approach is to create separate conda environments for conflicting packages. Based on the example above, ask yourself "If I need Python 3.10 in this environment, can I put `package-a` in a different environment?"

```sh theme={null}
# Create an environment for Python 3.10
conda create --name python-env python=3.10

# Create a separate environment for package-a
conda create --name second-env package-a=2.0
```

<Warning>
  Dependency resolution failures don't always happen because of version incompatibilities. Sometimes you might be working with repositories where packages have been filtered out; for example, if you are using conda with a local package <Tooltip tip="Any storage location from which software or software assets, like packages, can be retrieved and installed on a local computer.">repository</Tooltip> where packages have been filtered out for security or licensing reasons.

  In cases like these, sometimes there is no way to install a set of packages together with specific version constraints, even when using separate environments.
</Warning>

#### Only pin packages that require it

If specifying (or pinning) a version for `package-a` along with `python` is leading to solver errors, try only giving conda the name `package-a` and no version number. This will give conda's solver more options to evaluate.

```sh theme={null}
# Create an environment with only Python pinned
conda create --name python-env python=3.10 package-a
```

Since you haven't specified a version number for `package-a`, conda will attempt to find the latest possible version that works with Python 3.10.

#### Specify package ranges

If you want more control over `package-a`'s version, try specifying a version range for `package-a`.

<Note>
  When specifying a version range (with `<`, `<=`, `>`, or `>=`), make sure you surround that part of the command in quotes.
</Note>

```sh theme={null}
# Create an environment with only Python pinned
conda create --name python-env python=3.10 "package-a<2.0"
```

Since you've specified a version less than 2.0 for `package-a`, conda will attempt to find a version older than 2.0 that works with Python 3.10.

## Transitive dependency conflict

Because packages often depend on several other packages, which in turn often depend on other packages, another conflict type you will likely see is a *transitive dependency conflict*. Transitive dependencies occur when one package depends on another, which in turn depends on a third package. For example:

```mermaid theme={null}
flowchart LR
    id1[Package A] --> id2[Package B] --> id3[Package C]
```

In the above scenario, Package A depends on Package B and Package B depends on Package C. This makes Package C a transitive dependency of Package A.

Let's say you want to install Package A and another package, Package D, into the same environment. Package D requires version 3.5 of Package C. For the version of Package A that you want to install, its dependency, Package B, requires version 4.0 or higher of Package C. This is an example of a transitive dependency conflict. Package A doesn't conflict with Package D directly, but one of its dependencies does.

Try one of the strategies suggested for [solving the direct dependency conflict](#solving-the-version-conflict). Transitive dependency conflicts can be more complex to solve because the conflicting package or packages might not be directly connected to the package you're trying to install.