My current organization had adopted poetry before I arrived, and I eventually had to decide that we're reversing from poetry, back to pip and explicit usage of setuptools. It was too problematic, and was costing us in production DLL-hell bugs. The solver does not allow you to pin a constraint if it conflicts with the packaging metadata of your dependencies.
The stance of the poetry team is that any discrepancies should be fixed in upstream dependency. Hey, I love purity and platonic solids too, but... so that's not a completely crazy design decision, but we're in an NP problem here. That stance requires the cooperation of every single upstream package maintainer, which obviously, no one can actually operationalize. Here is a very old issue about this:
https://github.com/python-poetry/poetry/issues/697#issuecomm...
There is some movement, and acknowledgment that a tool is useless if you can't take it full-stack for your application. As of writing, the state of the art is to fork and patch things like fastapi and flask. That's nuts. I can make our stack work with the tested tools much more consistently, and there isn't much downside.
https://github.com/python-poetry/poetry/issues/697#issuecomm...
To me, that removes the value of using poetry. `poetry install <x>` is something you do very rarely. Propping up new python environments needs to happen very frequently. The convenience doesn't outweigh the operational costs.
tl;dr: I think poetry is really cool, and it looks like npm to a developer. It doesn't play nice with others, and that's by design. For production use, pip/setuptools solves more problems than people think it does. Sure, constraints.txt is a blunderbuss for a dependency resolver. However, it works. Especially if you are making more than one package for a real-world application. If you are maintaining a standalone library without complex dependencies, sure, go for it :)