Skip to content

Feature request: support for Conda-backed virtual environments #10537

@salimfadhley

Description

@salimfadhley

Issue Kind

Brand new capability

Description

Feature Request

Summary:
Allow Poetry to create and manage project environments using Anaconda/Miniconda instead of the built-in venv.

Motivation:
On some Windows systems, installing packages like NumPy or Pandas from source is difficult due to the lack of a C/C++ toolchain. Conda solves this by distributing pre-built binaries.

The current workaround is:

  • Manually create a Conda environment.
  • Install Poetry into that environment.
  • Activate it.
  • Run Poetry commands inside.

Problems with this approach:

  • Environment setup becomes a manual multi-step process instead of poetry install.
  • "poetry run" is no longer usable as intended, since Poetry does not own the environment lifecycle.

Proposed design

Add a configuration option in pyproject.toml:

[tool.poetry.env]
engine = "conda"                # default remains "venv"
conda-path = "/path/to/conda"   # optional
env-name = "custom-name"        # optional override

Behaviour:

  • Default naming follows Poetry’s existing environment scheme.
  • If engine = "conda", Poetry invokes Conda to create and manage the environment.
  • All normal Poetry workflows (poetry install, poetry run, etc.) work seamlessly.

Benefits

  • Simplifies setup for Windows where compilers are unavailable.
  • Retains full Poetry workflows.
  • Supports teams standardising on Conda.

Impact

The motivation for this issue is that on some platforms—particularly Windows—users may lack the necessary compiler toolchains required to build scientific Python libraries such as NumPy or Pandas from source. While Conda provides pre-built binary distributions that solve this problem, the current workflow requires manually creating and managing a Conda environment outside of Poetry’s control, installing Poetry inside it, and then running commands within that context. This breaks the simplicity of Poetry’s standard workflow, which is designed around a single command (poetry install) to set up a project environment and poetry run to execute commands in that environment.

By adding support for Conda as an environment backend, Poetry would streamline the setup process for users who rely on Conda, allowing them to keep the same developer experience as those using the default venv. This would ensure that poetry install works consistently across different systems, regardless of compiler availability, and that poetry run can still be used as intended. The improvement is especially important for teams working in mixed environments or organisations standardising on Conda, as it allows Poetry to integrate seamlessly into existing workflows while reducing friction for users who would otherwise have to maintain two separate environment-management steps.

Workarounds

Current workaround steps:
1. Use Conda (Anaconda or Miniconda) to manually create a new environment:

conda create -n myenv python=3.11

2.	Activate the environment:

conda activate myenv

3.	Install Poetry into this Conda environment:

pip install poetry

4.	Run poetry install inside the activated Conda environment to install project dependencies.
5.	To execute commands, activate the Conda environment first, then run poetry run ....

This sequence works but breaks the usual single-step workflow and prevents poetry run from automatically managing activation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureFeature requests/implementationsstatus/triageThis issue needs to be triaged

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions