I'm no longer using Poetry or Poetry2nix, and want to step down from poetry2nix maintenance.

Poetry has a number of upcoming large changes, which poetry2nix is unlikely to gain support for:

• PEP-621 pyproject.toml metadata
• Poetry 2.0

There are a number of poetry2nix specific challenges long-term:

• Dependency solving isn't very good
  I started working on that in https://github.com/adisbladis/poetry2nix-v2, but with uv gaining a lock file I don't see the point any more.

• Nixpkgs Python builders aren't good
  They should be replaced by https://pyproject-nix.github.io/pyproject.nix/build.html.

• The whole API is misdesigned
  mkPoetry* shouldn't exist. A python2nix tool should generate an overlay to use with environment composition primitives.
  See uv2nix for prior art.
  Having a default choice between sdist or wheel was a mistake. Users should be responsible for making this choice themselves as it shapes your entire user experience.

• Overrides
  This is my biggest annoyance in regards to maintenance, and was kind of accidental.

  I don't think python2nix tooling should come with overrides that taper over lock file deficiencies.
  Overrides are ephemeral in nature and bit-rot.
  It's better that external projects to take on this role, and let python2nix tooling focus on getting the semantics right.

Options

• Switching to uv

  My personal recommendation is to use uv & uv2nix instead.
  Uv2nix is still marked as experimental and might still undergo some breaking API changes, so this has some risks attached.

• Sticking with Poetry

  • Using nixpkgs dependencies

    If you're OK with using the Python package set from nixpkgs (ignoring poetry.lock) pyproject.nix is an option with it's Poetry pyproject.toml loader.
    This option is maintained and offers a migration path from Poetry to PEP-621.

  • Using dependencies from poetry.lock

    This is not currently a maintained use case anywhere.

• Pay for maintenance

  I'm open for contract work.