astral-sh/uv · error · anyhow::Error

Conda environment files (i.e., `{}`) are not supported

Error message

Conda environment files (i.e., `{}`) are not supported

What it means

Thrown in from_source_with_cache (crates/uv-requirements/src/specification.rs:366) when a RequirementsSource::EnvironmentYml reaches specification building: uv does not resolve conda packages, so conda environment files are hard-rejected with an explicit message rather than partially parsed (only the pip: section would be usable, which would silently drop conda deps).

Source

Thrown at crates/uv-requirements/src/specification.rs:366

                }

                Self {
                    source_trees: vec![SourceTree::SetupCfg(path.clone())],
                    ..Self::default()
                }
            }
            RequirementsSource::PylockToml(path) => {
                if !(path.starts_with("http://") || path.starts_with("https://") || path.exists()) {
                    return Err(anyhow::anyhow!("File not found: `{}`", path.user_display()));
                }

                Self {
                    pylock: Some(path.clone()),
                    ..Self::default()
                }
            }
            RequirementsSource::EnvironmentYml(path) => {
                return Err(anyhow::anyhow!(
                    "Conda environment files (i.e., `{}`) are not supported",
                    path.user_display()
                ));
            }
            RequirementsSource::Extensionless(path) => {
                let content = if let Some(content) = cache.get(path.as_path()) {
                    content.clone()
                } else {
                    let content = read_file(path, client_builder).await?;
                    cache.insert(path.clone(), content.clone());
                    content
                };

                // Detect if it's a PEP 723 script.
                if let Some(metadata) = Pep723Metadata::parse(content.as_bytes())? {
                    Self::from_pep723_metadata(&metadata)
                } else {
                    // If it's not a PEP 723 script, assume it's a `requirements.txt` file.

View on GitHub (pinned to f1a42680ff)

Solutions

  1. Extract the `dependencies:` → `- pip:` subsection of environment.yml into a requirements.txt and pass that to uv
  2. Recreate the full environment: conda deps must still be installed with conda/mamba — uv handles only the PyPI part
  3. Consider `uv import` to scaffold a uv project from an existing environment, then maintain deps in pyproject.toml

Example fix

# before
uv pip install -r environment.yml
# after
# requirements.txt = pip: subsection contents (flask, numpy...)
uv pip install -r requirements.txt
Defensive patterns

Strategy: validation

Validate before calling

fn is_environment_yml(path: &Path) -> bool {
    path.extension().is_some_and(|ext| ext.eq_ignore_ascii_case("yml") || ext.eq_ignore_ascii_case("yaml"))
        && path.file_stem().is_some_and(|stem| stem.to_string_lossy().contains("environment"))
}

if is_environment_yml(&path) {
    // extract the pip: subsection to requirements.txt before passing to uv
}

Try / catch

match RequirementsSpecification::from_source(src, &client_builder).await {
    Err(err) if err.to_string().contains("Conda environment files") => {
        // convert the file's pip section and retry with a RequirementsTxt source
    }
    spec => spec?,
}

Prevention

When it happens

Trigger: `uv pip install -r environment.yml` or `-r conda-env.yaml` where uv's source detection classifies the file as an environment.yml source; also programmatic RequirementsSource::EnvironmentYml(path).

Common situations: Migrating from conda/mamba workflows where `pip install -r environment.yml` (with its pip: subsection) was tolerated; handing uv an env file out of habit; CI shared between conda and uv jobs.

Related errors

AI-assisted analysis of astral-sh/uv@f1a42680ff (2026-08-16). Data as JSON: /api/errors/17f09dce369eb6d4. Report an issue: GitHub.