4 ms·

I think poetry is emerging as a consensus somewhat, and it’s been the most reliable tool in my experience

by rmorey 4y ago

jerrygenser 4y ago
dependency resolution even with caching takes way too long for larger projects, which requires a lot of setup and configuration when managing multiple inter-related projects that have many dependencies
woodson 4y ago
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 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.
- DangitBobby 4y ago
  That is really unfortunate.
- tomnipotent 4y ago
  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.
  - woodson 4y ago
    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.
- kortex 4y ago
  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.
  - woodson 4y ago
    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. Edit: Notably, not in other tools such as pip.

I think poetry is emerging as a consensus somewhat, and it’s been the most reliable tool in my experience

by rmorey 4y ago

I think poetry is emerging as a consensus somewhat, and it’s been the most reliable tool in my experience

dependency resolution even with caching takes way too long for larger projects, which requires a lot of setup and configuration when managing multiple inter-related projects that have many dependencies

woodson 4y ago

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 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.

DangitBobby 4y ago
That is really unfortunate.
tomnipotent 4y ago
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.
- woodson 4y ago
  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.
kortex 4y ago
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.
- woodson 4y ago
  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. Edit: Notably, not in other tools such as pip.