chore: fully switch to project/packaging configuration to pyproject.toml

[stegayet]

As of now, kombu uses setup.cfg, setup.py, and MANIFEST.in as project/packaging configuration files besides pyproject.toml. The idea would be to fully switch to the latter.

Some of those configuration items only needs to be migrated to pyproject.toml (mypy for instance), for some others, it will require more work (flake8 does not support pyproject.toml and could be replaced with ruff).

Note that this issue does not cover kombu package manager/build backend modernization.

I can work on this issue.

[Nusnus]

I don’t recall where the other issue is to reference, but there was already a discussion about this topic last year.
Long story short, we want to refine all of the repositories on the same toolchain etc.

Therefore, it is less recommended to upgrade repo by repo. Instead, it is better to start a discussion about the entire toolchain to evaluate (with the community) what stack/config best fits compared to our current toolchain.

You’re welcome to initiate the effort and take the lead @stegayet.
If you’re interested, I’ll describe better what is required and how we should proceed. If not, it will be done as part of our roadmap for 2025, with an undefined ETA.

[stegayet]

Hey, thanks for replying, I can indeed start a discussion around the whole toolchain, let me try to have something ready by the end of the week, looks good to you?

[Nusnus]

Thank you!
I’ll post here this week some guidelines to focus the effort in the right direction.
You can start by taking a look at celery, kombu, and pytest-celery. Check out the CI (GitHub Actions/Tox), the Makefiles, the doc folder and its own Makefile. You can start comparing in your head how we do stuff just to get a taste of the diff between these repos.

I can indeed start a discussion around the whole toolchain

I prefer we maintain the conversation here for now, @stegayet, until we define clear goals and agree on the action items and guidelines.

Lastly, @auvipy and I are using these tools a lot to maintain the org. We will need to be highly involved to ensure any upgrade indeed works for us as well, as the daily clients of the toolchain.