Claim support for Python 3.8 - 3.13

[jugmac00]

• drop support for Python < 3.8
• enable local testing via tox
• clean up some metadata

[jugmac00]

While upstream support for Python 3.8 has ended, we still need it to ease a transition progress, so I would be very happy if we could keep that for a while.

[jugmac00]

There will be more PRs to come, e.g. removing pbr and using hatchling as the other projects here in the testing-cabal org are using. I also pinged @cjwatson to request access to PyPI to create a new release once this and the other PRs have landed.

[jelmer]

is there some way we can do this without adding another list of supported python versions? This list is out for date (and thus tox.ini is broken) for some of the other testing-cabal projects.

[jelmer]

(perhaps split out adding tox.ini for a separate PR, it seems unrelated to the main change?)

[jugmac00]

Some colleagues at Canonical are using a shared template for all their project (https://github.com/canonical/starflow), but I have not looked into how that works exactly. And afaik this only refers to CI workflows, and not to local testing. And I would love to be able to test changes locally before pushing them to github.

What I have used in the past, is all-repos, which is a great tool to handle all / many repositories of e.g. a github org. You can apply changes to all of them at once, and automatically create pull requests, but for that the repos need to be uniform first. That is something I used before for the zope repositories, and at my old workplace (https://jugmac00.github.io/tags/all-repos/). I could image using that tool in the future for the testing-cabal org if all maintainers are on board and if we make all repos uniform - but that might be a long term project.

What we also can do in the meantime, is to use the https://pypi.org/project/check-python-versions/ linter, which would error out if e.g. the content of tox.ini diverges from the one of setup.cfg or the gh workflow. This would make sure one project in itself stays consistent, but would not help with consistency across projects.

[jelmer]

We still have to update those files. Do we need tox at all here?

[jugmac00]

tox offers the great advantage of being able to test your changes locally across all supported Python versions.

If there is no tox configuration, I either

• just test a single version, push to github, and hope things won't break for other versions, which probably sends out notification to all maintainers
• or I need to create 6 different local venvs, and manually run the test suite for each of them, and the next time make sure there were no dependency updates, which tox handles automatically

The latter solution does not scale, especially as I contribute (ligthly) to hundreds of projects.

I do see your point, though. tox does not offer a way to autogenerate test config from a build configuration, maybe hatch can do this, never looked into this.

A small number of projects I contribute to, also do not want a tox configuration for the reasons you mentioned. I then create a local tox configuration which I do not check in for my personal use. I am happy to go that route if you prefer to not have a tox configuration.

[bigjools]

I don't think you can avoid 2 lists if you want to test locally. However, there are some pointers in here
pypa/hatch#669
to help with getting Hatch matrices working with Github Actions.

[bigjools]

This comment in particular pypa/hatch#669 (comment)

[jugmac00]

I removed the tox.ini from the MP, and keep it locally when working with this project for now.

I made this MP as minimal as possible, so I hope it can get merged soon. As a follow up, I will remove pbr in favor of hatchling.

I currently do not have the capacity to redesign the workflow for the testing-cabal projects, i.e. looking into the hatch solution.

[stephenfin]

Looks mostly good, but any reason we can't just drop Python 3.8 as well? It's EOL upstream for over 3 months and I wouldn't be surprised to see GitHub dropping support for it in their runners before long. Users can always fall back to the older releases if they need 3.8 support but we can choose not to support it going forward.

[jugmac00]

@stephenfin See my comment above, #10 (comment) - we are currently migrating a major application from 3.8 to 3.12 and keeping 3.8 would ease the migration process. FWIW, while Python 3.8 is not maintained upstream any more, it is still maintained via Ubuntu LTS.

I am more than happy to follow up with a MP to remove support for Python 3.8 once we are done, or even very soon after this one got merged.

tl/dr to ease the migration process I would love to have a version which is both compatible with 3.8 and 3.12 at the same time

[stephenfin]

Ack. Apologies, I missed that comment.

[stephenfin]

LGTM. I'll hold off merging in case @jelmer wants to take a second spin through this. I would like to see Python 3.8 support dropped in the next version (0.7?) but we can discuss that when we get there.