chore: switch to hatchling

[henryiii]

Quick examples of moving to hatchling. Slightly less config, 2 seconds faster, less verbose build messages, ~~reduced chance of version conflicts~~, and slightly cleaner output. Other packages using hatchling include pipx, black, tox4, etc.

Just thought I'd throw it out there. Current system is completely fine too. Mostly making the PR since I tried it out and already had it. One benefit of PEP 621 is that it's easy to switch to the best performing backend. :)

PS: It occurred to me on the version conflicts (some packages limit setuptools < 60), that you don't have hatchling or setuptools when you have a wheel, so that should never be a problem. This is very much just a developer choice.

From #655.

[henryiii]

@ofek, I just swapped from setuptools to hatchling, and the tox_to_nox extra (which is declared that way and used that way) is getting normalized to tox-to-nox, which causes it to silently start failing. I don't see any way to provide a backward compatible tox_to_nox extra. AFAICT, this is more likely Pip's issue, since PEP 685 was accepted? I see no mention there of PEP 685 support.

[ofek]

https://hatch.pypa.io/latest/config/metadata/#allowing-ambiguous-features

[ofek]

Other packages using hatchling

See https://hatch.pypa.io/dev/users/

[henryiii]

The pyproject.toml formatter is insisting the comment be removed.

[ofek]

https://github.com/tox-dev/pyproject-fmt/issues/16

[FollowTheProcess]

Nice, looks like this is basically ready to go?

[henryiii]

Yes, except for the issue with pyproject.fmt not allowing a comment.

[FollowTheProcess]

Looks like the recent fail is just adding an extra newline? If we fix that then I'm happy to merge this 👍🏻