Modernize the build: switch to hatchling

[offbyone]

• generate the version from vcs metadata (tags)
• use hatchling as a build system

This is per our discussion in email; I'm not sure this is the way you want to
take things, but here's a pivot to hatchling to build.

The main takeaways here are very low configuration building, and versioning from
tags. Actual usage is pretty conventional:

• pip install -e .[dev] gets you tox, wheel, and the test dependencies.
• pip install -e .[test] gets you pytest and the various testing dependencies
• tox just works
• python -mbuild generates an sdist
• twine is provided for publication

[staticdev]

Thanks a lot @offbyone. I put some topics to discuss. Also would be nice if we have something mentioning on CONTRIBUTING.rst about the new tool and how to manually package/publish the application after this change.

[offbyone]

Hatchling is really minimal; your development tools for dependency management basically become "pip" more or less intentionally. That's part of the appeal to me; it lets each developer decide how to manage virtualenvs, tools, etc (me, for example, I use direnv, and poetry just interferese with those)

[sigmavirus24]

Please don't use the VCS integration. This has caused tonnes of headaches for gitlint.

[offbyone]

Fair enough! I've found it really nice to work with over in PyHamcrest, but ymmv, and it's your project :D

How do you prefer to handle dev versions? One of the reasons I landed on hatch.vcs is because it solved the versioning problem for me when working on the next release really painlessly. What version would you like me to put into this?

[staticdev]

Great work @offbyone! For approval I would just want to release 4.0.0, to do a release and then add this one as following version. Any problem @sigmavirus24 ?

[offbyone]

I don't follow why this would be a major version bump in the package; there should be no user-facing changes from this PR. My inclination would be to not change the version at all, from this.

[sigmavirus24]

I don't follow why this would be a major version bump in the package; there should be no user-facing changes from this PR. My inclination would be to not change the version at all, from this.

4.0 was planned for already. But I almost want to include this for 4.0 because distro packagers are going to throw a fit probably

[offbyone]

It looks like GHA still thinks it needs to run the test suite with 3.10. If I had to guess I'd say that's a leftover from the original revision of the PR, since it's not in the workflow any more.

[staticdev]

Lgtm. I dont have permissions to change required checks though.

[staticdev]

@sigmavirus24 @offbyone I wasn't lucky publishing it with hatch. Opened an upstream issue pypa/hatch#833

[ofek]

pypa/hatch#833 (comment)

[staticdev]

Thanks for the prompt response @ofek. Disabling strict naming did the trick, but still we have unhappy customers #1145

I created a PR with the config I used to be able to publish until the issue is solved #1144.

[offbyone]

@sigmavirus24 I'm starting to think that my proposal to use hatch was a mistake based on the many, many packaging edge cases we've encountered along the way.

[ofek]

To be clear the issue for which you are working around is that PEP 625 standardizes the naming of source distributions and PyPI doesn't acknowledge that so modern tools like build and Hatchling are at odds with the implementation of the main package index. The option to disable normalization/PEP 625 is exclusive to Hatchling and fixes this project's builds to maintain the status quo.

There is nothing more that can be done and as far as I can tell everything is now working.