RFC: Use Poetry for package management

[l0b0]

Another suggestion based on using it in a few other projects: Poetry improves Python package management in several ways over pip:

1. The list of top-level dependencies and the lock file are separate.
2. The main configuration is in the pyproject.toml file, which is also supported by tools like black, coverage and mypy, so we could actually reduce the number of configuration files.
3. Runtime and development dependencies can all easily be specified in the same configuration. It's also easy to specify other collections of packages, for example for subprojects or testing, using extras.
4. The lock file uses checksums by default, which is really clunky in pip.
5. The lock file contains a checksum of the relevant part of pyproject.toml, and warns if the lockfile is out of sync with the main configuration.
6. Optional dependencies are supported out of the box.
7. It specifies the supported Python versions.
8. 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.

Cons:

1. It still needs to be installed using Pip.
2. It's another command to learn.

[duckontheweb]

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.

[gadomski]

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.