Open l0b0 opened 3 years ago
I'm +1 for this change. I use poetry for other projects and really like it. I'm also in favor of starting to consolidate around a pyproject.toml
file, which poetry uses.
Tl;dr: 👎🏼 because I don't think the juice is worth the squeeze.
I'm also in favor of starting to consolidate around a pyproject.toml file
We've done this bit: https://github.com/stac-utils/pystac/pull/1100
As for the rest of @l0b0's points, some of them are addressed by #1100 (2, 3, 6). Some that aren't:
The list of top-level dependencies and the lock file are separate.
I'm not convinced a lock file is useful for a library like pystac. I'm happy to be persuaded otherwise.
It specifies the supported Python versions.
Again, seems like a nice-to-have rather than a needs-to-have, and should be therefore weighed against the added complexity of adding a new build system.
It's possible to run non-Python commands within the context of the virtualenv without sourcing the activate script, for example running poetry run git gui& (will run the pre-commit hooks within the virtualenv when committing inside the GUI) or poetry run ./scripts/test.
I don't quite see the value in this, but I'm not a poetry user so maybe I'm missing something.
Another suggestion based on using it in a few other projects: Poetry improves Python package management in several ways over
pip
:pyproject.toml
file, which is also supported by tools likeblack
,coverage
andmypy
, so we could actually reduce the number of configuration files.pip
.pyproject.toml
, and warns if the lockfile is out of sync with the main configuration.activate
script, for example runningpoetry run git gui&
(will run the pre-commit hooks within the virtualenv when committing inside the GUI) orpoetry run ./scripts/test
.Cons: