Configure PyPI for release automation

[intgr]

PR #1950 introduced automation for making releases. But when I tried this out on Tuesday, it did not work: https://github.com/typeddjango/django-stubs/actions/runs/8892716988/job/24417384679

Token request failed: the server refused the request for the following reasons:

• invalid-publisher: valid token, but no corresponding publisher (All lookup strategies exhausted)

It requires some setup to be done on PyPI side. I believe only @sobolevn can do it. See below:

---

#2087 (comment)

@intgr Was the trusted publisher set up on the PyPI side? Do you have access to see if it's configured?

It should just be to follow this if it's not: https://docs.pypi.org/trusted-publishers/adding-a-publisher/

Should just be to fill in and post a form

#2087 (comment)

Owner: typeddjango
Repository name: django-stubs
Workflow name: release.yml
Environment name: release

[sobolevn]

Done!

[sobolevn]

We can try 5.0.1 release, since we have lots of PRs with stub fixes.

[intgr]

@sobolevn Looks like you only configured the django-stubs package? We also need django-stubs-ext.

[flaeppe]

We don't have any release workflow for django-stubs-ext yet. I don't know what we should have as a trigger?

• Should we always release it, regardless if files under ext/ were changed or not? Then it's simple to add it.
• Should we only release if files were changed? Then we need to diff files.

Main thing to think about is that if we want the ability to keep different release numbers between the packages we can't use the same GitHub releases.

[intgr]

Doh, sorry. I had a brief look at the diff before and saw it doing something with ext. But I was misled by the build-and-check workflow

django-stubs/.github/workflows/test.yml

Lines 174 to 179 in ea8e425

	python3 -m build --sdist --wheel .
	python3 -m build --sdist --wheel ext/
	- name: Check package metadata
	run: |
	twine check --strict dist/*
	twine check --strict ext/dist/*

---

if we want the ability to keep different release numbers between the packages we can't use the same GitHub releases.

Diverging version numbers are a PITA that we don't want in any case. Otherwise we would also need a separate set of git tags for django-stubs/django-stubs-ext, separate release notes, etc. And possibly other maintenance complexity.

The closest thing to a policy is currently documented in ext/setup.py

NB! For clarity, keep version major.minor.patch in sync with django-stubs.
It's fine to skip django-stubs-ext releases, but when doing a release, update this to newest django-stubs version.

So, you could make the ext release conditional on whether stubs and ext version numbers match in setup.py.

But I think releasing both packages regardless of whether there were any changes in ext is clearer and also more foolproof.

[sobolevn]

But I think releasing both packages regardless of whether there were any changes in ext is clearer and also more foolproof.

Yeah, I agree. It should not be a problem to release just the same package. But it can be a problem not to release something.

[flaeppe]

Yeah I'm in on this as well. I don't think there's any harm in releasing django-stubs-ext regardless of changes.

We just have to think a little bit about the design of the workflow(s) so that the releases can fail and be retried independently

[intgr]

@flaeppe Are you interested in adding release automation for django-stubs-ext too?

the design of the workflow(s) so that the releases can fail and be retried independently

That would be nice to have. But even a non-retriable release workflow would be more useful than what we have now.

[flaeppe]

Sure I can try when I'm able to (see #2150)