Mixing packages from two different sets will cause trouble, we should not do that. The current status is confusing but inevitable if we want to allow poetry as build system in python-packages.nix.

@FRidh I just added this to my PR description:

I'm a bit skeptical of this PR myself as it mixes pythonPackages derivations and poetry2nix derivations.
OTOH the upstream officially sanctioned way of installing poetry is this method which the poetry2nix package mimics very closely so I think that this will be preferred.

Poetry provides a custom installer that will install poetry isolated from the rest of your system by vendorizing its dependencies. This is the recommended way of installing poetry.

Their installer installs poetry with deps in a separate location. After that, you will manage your envs entirely using poetry, so there will be no mixing with packages provided differently.

Using pip to install poetry is also possible.
Be aware, however, that it will also install poetry's dependencies which might cause conflicts.

This is how we install things in python-packages.nix, all packages need to be compatible. This of course makes it very challenging due to the shear amount of dependencies poetry itself has. Ideally, the poetry build system would be separated from the poetry application, but from a UI POV that's exactly what is not done.

The current pythonPackages.poetry derivation is not useful for anything except as a build-system as it leaks dependencies in normal usage and barely even that since it has overrides in a let block in the derivation which leads to collisions.

The way poetry is vendored in Nixpkgs ensures no propagation of dependencies so there is no collisions with the rest of pythonPackages.

The only new problem I can think of that comes with this PR is that it potentially introduces a problem if a build imports poetry (as opposed to calling the poetry script).
This is already a lot better than the status quo.