Update release documentation, workflow and build-and-check job to uv

[intgr]

Aligns parts of django-stubs with the changes I have been making in djangorestframework-stubs:

• build-and-check changes: Switch to uv to manage dev dependencies  djangorestframework-stubs#797
• release changes: Switch release workflow to uv djangorestframework-stubs#838
• Docs: Test new release workflow: version 3.16.4a1 release djangorestframework-stubs#840

Changes:

• Using uv build instead of PyPI build dependency
• Added build-and-check check to ensure uv.lock is up to date
• Updated from Python 3.12 to 3.13

[intgr]

Related note: djangorestframework-stubs uses build system uv_build instead of hatchling. https://github.com/typeddjango/djangorestframework-stubs/blob/73ce41a8b87f83f08d33c5d4cda5f52b6835ee10/pyproject.toml#L58-L60

I'm not sure if there are any significant differences between the two. I can submit a PR to change it here too, if anybody thinks that's beneficial.

[Copilot]

Pull Request Overview

This PR modernizes the build and release workflows by migrating from traditional Python build tools to uv, a modern Python package manager. The changes align django-stubs with similar updates made to djangorestframework-stubs.

• Replaced PyPI build dependency with uv build command
• Added lockfile validation to ensure uv.lock stays up-to-date
• Updated Python version from 3.12 to 3.13 across workflows

Reviewed Changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
CONTRIBUTING.md	Updated release documentation to reference pyproject.toml instead of setup.py and added uv lock step
.github/workflows/test.yml	Migrated build-and-check job to use uv with lockfile validation
.github/workflows/release.yml	Updated release workflow to use uv build instead of Python build module

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[UnknownPlatypus]

I'm not sure if there are any significant differences between the two. I can submit a PR to change it here too, if anybody thinks that's beneficial.

Don't have strong opinion on that, I think they both work well for this kind of simple package.
I'll probably don't bother to swap since it's currently working and will probably for the years to come but if you'd prefer to unify and can make it work I'm fine with it too

[ngnpope]

I'm not sure if there are any significant differences between the two. I can submit a PR to change it here too, if anybody thinks that's beneficial.

For my 2¢, I'm happy for this to be switched to the uv-build backend. One less explicit dependency (as uv already bundles its own build backend).

[ngnpope]

Can we get rid of twine in favour of uv publish?

[intgr]

Publishing (release.yml) doesn't use twine (at least not directly), it uses pypa/gh-action-pypi-publish@v1.13.0.

This is just doing some checks on every PR build. According to twine docs: "Checks whether your distribution’s long description will render correctly on PyPI"

[ngnpope]

🤦🏻 Of course, scanned across that too quickly!

However, having now looked at this comment and checked the source myself, I think we can just remove this step entirely - it only checks that rST can render properly and we're using markdown - so it's effectively a noop.

[intgr]

Will do in a follow-up