I really hope not. I used it for a while, but the “wontfix” attitude (e.g. PEP440 related issues: https://github.com/python-poetry/poetry/issues/6013, or the issues with pytorch cpu packages) made me go back to regular pip and use “pip freeze” for locking package versions in place.
I understand your frustration, but the poetry team's response makes sense. The situation you got yourself is quite strange. System package python environments are notoriously nasty (frankly they were a mistake, but they emerged before venv, so it's hard to fault).
Non-PEP440 compliant libraries are also a pain in the ass.
Put both those facts together and you are playing with fire. In all likelihood you will eventually footgun yourself and end up with a python env superfund.
Just use virtual envs for everything.
I say this coming from over a decade of python experience and lots of time spent installing python in exotic environments.
Oh, I agree in principle, but as a user it means that something that worked up until poetry<1.2.0 broke. I understand that it's not their fault if Python distributions and packages don't comply with PEP440, and it's up to maintainers to fix it. Unfortunately, similar issues affect quite popular packages such as PyTorch, where the computation backend/version (cpu, cuda) is added as a local specifier ("1.12.1+cu116"), leading to all kinds of dependency resolver issues in poetry.
The PEP440 issue you linked to is a positive for Poetry, not a negative. You shouldn't be installing packages into your distro-managed Python environment, that's just asking for problems.
This issue is not restricted to installing packages into your distro-managed Python environment. I had Poetry-managed environments that, after upgrading to poetry>=1.2.0 stopped working (e.g., I couldn't run "poetry update" anymore) because of these issues.
I don't treat Python packaging tools as my religion. If one doesn't fulfill its purpose, I use another solution. Whether that's a positive or negative for the tool isn't my concern.
