Switch to pyproject.toml + PEP621

[UnknownPlatypus]

Fixes #1570
Fixes #2641

This revives and update #1570 allowing us to use PEP621 and remove the SETUPTOOLS_ENABLE_FEATURES=legacy-editable we had to use and that broke ci recently.

The pyproject.toml was intially generated using hatch new --init and tweaked to keep existing ordering / comments.

I've checked what differs between the pypi current dist and what is build here and found the following differences:

• we no longer ship the tests folders ( which is good ?)
• we no longer ship the django_stubs.egg-info folder in the sdist distribution which I believe is expected since it's a setuptools artifact

Test plan

• python -m build ext/ && python -m build
• pip install -r ./requirements.txt && run the whole ci locally

[ngnpope]

Nit: Sort tool block alphabetically, i.e. move after [tool.codespell]?

[UnknownPlatypus]

I kinda want to keep it close to the rest of the package metadata since it's use to build. No strong feeling tho

[ngnpope]

Also wondering if we could replace ./scripts/stubtest.sh with hatch's scripts so that you can just run hatch run stubtest? 🤔

[UnknownPlatypus]

Also wondering if we could replace ./scripts/stubtest.sh with hatch's scripts so that you can just run hatch run stubtest? 🤔

I think this should be in a separate pr and we might have to consider UV too for that.

This pr currently doesn't use hatch but only the hatchling build backend

[ngnpope]

This pr currently doesn't use hatch but only the hatchling build backend

Ah, yes, got muddled by the [tool.hatch.build] 🙃

I think this should be in a separate pr and we might have to consider UV too for that.

If you're considering uv instead, then have you thought about the uv build backend instead of hatchling?

[sobolevn]

let's please not replace sh scripts with hatch 🙏
I am using sh for 15+ years now and I have no idea what hatch is.

[sobolevn]

One last question: right now our build-and-check-metadata uses different flags from the final release

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

Lines 170 to 171 in 81321eb

	python3 -m build --sdist --wheel .
	python3 -m build --sdist --wheel ext/

Is it ok? Or should we adjust python -m build flags?

[UnknownPlatypus]

Is it ok? Or should we adjust python -m build flags?

I tested running python3 -m build --sdist --wheel . and python3 -m build . and got exactly the same sdist and wheel.

python3 -m build --help does say it's slightly different but recommend to not use any flags so I've removed them.

usage: python -m build [-h] [--version] [--verbose] [--sdist] [--wheel] [--outdir PATH] [--skip-dependency-check]
                       [--no-isolation | --installer {pip,uv}] [--config-setting KEY[=VALUE]]
                       [srcdir]

    A simple, correct Python build frontend.

    By default, a source distribution (sdist) is built from {srcdir}
    and a binary distribution (wheel) is built from the sdist.
    This is recommended as it will ensure the sdist can be used
    to build wheels.

    Pass -s/--sdist and/or -w/--wheel to build a specific distribution.
    If you do this, the default behavior will be disabled, and all
    artifacts will be built from {srcdir} (even if you combine
    -w/--wheel with -s/--sdist, the wheel will be built from {srcdir}).

[ngnpope]

👍🏻

[sobolevn]

Thanks everyone!