Centralize configuration in pyproject.toml

[wisp3rwind]

Most things can be configured in pyproject.toml. We were already using that in some cases (e.g. ruff). This PR compeletes this and removes setup.cfg entirely.

Additionally, this moves some entries in pyproject.toml from tool-specific sections (namely poetry) to general sections.

Draft because I want some CI feedback, and because it should also be possible to express dependencies in the general rather than poetry-specific format. (Which would for example enable the usage of uv, which is way faster.)

The individual commits in the PR should be easy to review.

[snejus]

I tend to keep project / dependencies specification separately from linters configuration. This way, seeing a change in pyproject.toml my brain instantly associates it with an update to the dependencies or the package; same applies to setup.cfg.

On the other hand, seeing that ruff does not support setup.cfg, and having to choose between ruff.toml and pyproject.toml for its config, I probably lean towards the latter.

And now for the sake of consistency, I guess, we can move all linters config to pyproject.toml, so I'm fine with this change.

[wisp3rwind]

I tend to keep project / dependencies specification separately from linters configuration. This way, seeing a change in pyproject.toml my brain instantly associates it with an update to the dependencies or the package; same applies to setup.cfg.

On the other hand, seeing that ruff does not support setup.cfg, and having to choose between ruff.toml and pyproject.toml for its config, I probably lean towards the latter.

And now for the sake of consistency, I guess, we can move all linters config to pyproject.toml, so I'm fine with this change.

I see your point: It would be nice if there were a clear separation into two files: a package manifest and a file for tooling configuration. However, as of now, both are mixed up already (with ruff, poe, poetry config in pyproject.toml).

I came here originally because I wanted to run tests with a uv-managed virtual environment, which would require a dependency specification that uv can read. This should be possible (as mentioned above) by using project.dependencies key (and related ones) in pyproject.toml. I've been working on that locally, but not yet pushed it to this PR. Then I got distracted into checking out what kind of information can be specified in pyproject.toml these days, which is how the above came about. That said, I'd argue that something like the fourth commit should go in, but I don't feel as strongly about the first three commits.

Related: https://stackoverflow.com/a/56523197/3451198

[wisp3rwind]

I came here originally because I wanted to run tests with a uv-managed virtual environment, which would require a dependency specification that uv can read. This should be possible (as mentioned above) by using project.dependencies key (and related ones) in pyproject.toml. I've been working on that locally, but not yet pushed it to this PR.

Turns out that it's still a little early to achieve this: python-poetry/poetry#9751 (uv does support dependency-groups already).

[citelao]

I've been working with the poetry folks to get dependency-groups working, but it's taking some time.

In the meantime, a bit off-topic, but as someone who prefers uv, I've been using poetry "via" uv:

# The latest version of poetry is unsupported:
# uv tool install poetry --with poetry-plugin-shell
# (^ if you already ran that, run `uv tool uninstall poetry`)
uv tool install [email protected]
uv tool install poethepoet

poetry install

# poetry shell, poe test, ...

EDIT: updated to use a supported version of poetry.