drop python3.8

[RonnyPfannschmidt]

No description provided.

[RonnyPfannschmidt]

@webknjaz @nicoddemus

while working on this i was wondering if we can create a reasonable workflow for release proposals that always opens a release pr that uploads to test-pypi and has a deploy step to upload to pypi/git tags

[nicoddemus]

while working on this i was wondering if we can create a reasonable workflow for release proposals that always opens a release pr that uploads to test-pypi and has a deploy step to upload to pypi/git tags

Should be doable.

I assume the objective to uploading to test-pypi first would be to be able to easily test the artifact, correct? Also, it would be nice for the official deployment to use the exact same artifact that was uploaded to test-pypi, of course.

[webknjaz]

Are you going to drop master separately?

[RonnyPfannschmidt]

just preparing the switch, not doing directly after

[webknjaz]

I'm kinda doing this in my automations. The trigger is workflow_dispatch and one has to type in the desired version number in the form on GitHub. I then generate the changelog commit, build the dists with that, test those dists and pause pre-PyPI. At this point, yes, the TestPyPI dists are testable. But note that those uploads are immutable, and you won't be able to reuse the same version if you decide to cancel the release and try again.
That said, the GHA workflow artifacts are also testable.
Anyway… once the PyPI publishing unpauses, my workflows upload to PyPI, and only then do the "post-publish" changes like pushing the release branch, opening a PR with that and pushing a tag on top of that branch that corresponds exactly to the commit that produced the dists (this is usually a changelog generation commit). GitHub Releases are created together with Discussions attached. I pass the Towncrier commit as a patch file between the jobs and then re-apply it later when I get to mutating Git.

I did have an idea that maybe that release PR could be actually created earlier in the process and then just the tag would be pushed, but never got to experimenting with this aspect in practice.
This is partially because I don't like separate “release” workflows and instead build this automation around the regular test workflow with more conditionals that just don't run in regular PRs / pushes.

Let me know if you want a demo of this all.

[webknjaz]

FWIW, I find it better to use a .gitignore for this purpose. It seems more natural in the context of Git… Plus I often put allowed/disallowed file patterns in so it's only possible to commit what's expected.

Also, maybe consider putting this dir into doc/?