Update package metadata

[ofek]

Background

Hello there! The Python packaging ecosystem has standardized on the interface for build backends (PEP 517/PEP 660) and the format for metadata declaration (PEP 621/PEP 631). As a result, the execution of setup.py files is now deprecated.

So, I'm spending my free time updating important projects so that they are modernized and set an example for others 😄

related: jazzband/help#313

Summary of changes

This implements PEP 621, obviating the need for setup.py (see note), setup.cfg, and MANIFEST.in. The build backend hatchling (of which I am a maintainer in the PyPA) is now used as that is the default in the official Python packaging tutorial. Hatchling is available on all the major distribution channels such as Debian, Fedora, Arch Linux, conda-forge, Nixpkgs, Alpine Linux, FreeBSD/OpenBSD, Gentoo Linux, MacPorts, OpenEmbedded, Spack, MSYS2, etc.

Notes

• The version is now sourced directly from debug_toolbar/__init__.py, removing a release step
• The source distributions on PyPI are erroneously shipping a build artifact *.egg-info from python setup.py develop; this is now fixed
• Let me know if I should remove setup.py, I followed https://github.com/urllib3/urllib3/blob/main/setup.py
• I updated the pin for the pypa/gh-action-pypi-publish Action https://github.com/pypa/gh-action-pypi-publish#-master-branch-sunset-

[matthiask]

Thank you! I like the general direction. I have yet to start converting any packages to the new format so I'm not able to judge if this is the best way to do it.

I have never heard about hatch or hatchling before. I see that it is a pypa repository, and this makes me feel warm and fuzzy inside :) so that's good. But I've certainly seen alternative build systems being used. Why should we use hatchling? (As you see I do not have a strong opinion here myself.)

I remember a discussion re. using something like this in Django proper. It was judged to be too early. I think django-debug-toolbar may be a good place to shake out the last (ha!) bugs but it still is a relatively high-profile project for Django users and I am wary to break things. Is the "new way" stable enough?

I don't know about leaving setup.py in there. GitHub seems to require it. But, if you leave it in there, you should probably add a sys.exit(...) above the commentary that the lines below will never be executed, otherwise they may be :-)

Thanks!

[hugovk]

Looks good, thanks!

One suggestion: shall we add https://github.com/tox-dev/pyproject-fmt/ to pre-commit to consistently format pyproject.toml?

That would make it easier to diff pyproject.toml across different Jazzband projects.

(I especially found https://github.com/abravalheri/validate-pyproject helpful when migrating to setup.cfg to pyproject.toml, could be useful in the future too?)

[tim-schilling]

I don't have a strong opinion one way or another for packaging, but it seems like hatch is mature enough for us to use. I would suggest us running a test with test.pypi.org first. I've made a request to the owner of the django debug toolbar package on test.pypi.org to add me as an owner. If I'm able to get those permissions, I'll add you as well @matthiask.

[ofek]

Why should we use hatchling?

Not a complete list but here's from a recent comment -

Hatchling:

• Supports static analysis tools for editable installations by default whereas the new setuptools does not i.e. it requires enabling an option for IDEs to work.
• Uses Git-style glob patterns rather than stdlib globs to better match user expectations.
• Allows easy and explicit control of what gets shipped in the sdist target whereas with setuptools it's an objectively confusing mix of conditional wheel options and a MANIFEST.in file.

I don't know about leaving setup.py in there.

Can I remove it?

[matthiask]

Hatchling: [...]

Thanks!

Can I remove it?

I think it probably makes more sense to copy urllib3 there as well? See community/community#6456

[ofek]

Done!

[ofek]

@hugovk

One suggestion: shall we add https://github.com/tox-dev/pyproject-fmt/ to pre-commit to consistently format pyproject.toml?

Can we do that in a separate PR?

[hugovk]

Sure!

[tim-schilling]

@matthiask It'll take at least one more week until I have ownership of the test pypi repo. Do you want to do a release with the code before this change, then this after we test the release process on test.pypi.org? Or batch it all together?

[matthiask]

@tim-schilling I think it's fine to batch it. We can always push another release or revert in the worst case.

[ofek]

another just merged jazzband/prettytable#212

[tim-schilling]

Alright I'm good with this. Thank you for the PR! @matthiask I don't feel strongly enough about testing with test.pypi.org to stop us from releasing this.

[matthiask]

Me neither, let's merge it then. Thanks all!

[pauloxnet]

Great. Can we create a recipe with steps to apply this update in other jazzband packages ?

[ofek]

First step: https://hatch.pypa.io/latest/intro/#existing-project

[hugovk]

@hugovk

One suggestion: shall we add https://github.com/tox-dev/pyproject-fmt/ to pre-commit to consistently format pyproject.toml?

Can we do that in a separate PR?

Please see PR #1700.