Update package metadata #1690

ofek · 2022-10-24T03:38:54Z

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 · 2022-10-24T12:48:22Z

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 · 2022-10-24T14:03:52Z

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 · 2022-10-24T14:11:10Z

Hatchling: [...]

Thanks!

Can I remove it?

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

ofek · 2022-10-24T14:27:25Z

Done!

ofek · 2022-10-25T14:58:04Z

@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 · 2022-10-25T15:25:18Z

Sure!

tim-schilling · 2022-10-27T10:50:27Z

@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 · 2022-10-28T06:57:33Z

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

ofek · 2022-10-29T19:26:07Z

another just merged prettytable/prettytable#212

docs/contributing.rst

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 · 2022-11-02T19:54:03Z

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

pauloxnet · 2022-11-02T20:33:26Z

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

ofek · 2022-11-02T20:41:28Z

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

hugovk · 2022-11-02T22:05:57Z

@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.

Most of the changes to `pyproject.toml` were made by running `hatch new --init` (see https://hatch.pypa.io/latest/intro/#existing-project). Most of the changes to the other files were based on the changes made in django-commons/django-debug-toolbar#1690. ### `release.yml`: * `hatch version` is run instead of `hatchling version` (as is done in the PR mentioned above), as the latter crashes with the error: ``` hatchling.plugin.exceptions.UnknownPluginError: Unknown version source: vcs ``` Installing `hatch` takes considerably longer than just `hatchling`, but I think it's still acceptable. * Updated the `pypa/gh-action-pypi-publish` action from the sunset `master` branch to `release/v1`; see warning at https://github.com/jazzband/django-simple-history/actions/runs/9246937361. Also replaced the deprecated `repository_url` with `repository-url`; see https://github.com/pypa/gh-action-pypi-publish/blob/v1.8.14/action.yml#L15 ### `.pre-commit-config.yaml`: * Added some pre-commit hooks for formatting and validating `pyproject.toml` ### `MANIFEST.in`: * Removed `MANIFEST.in`, as the default `[tool.hatch.build.targets.sdist]` configuration (in `pyproject.toml`) includes all files not ignored through our `.gitignore`; see https://hatch.pypa.io/latest/plugins/builder/sdist/#default-file-selection ### `pyproject.toml`: * Didn't include the `license` field, as the docs recommend using a `License ::` classifier instead - see https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license * The classifier "Programming Language :: Python :: 3" was changed to "Programming Language :: Python :: 3 :: Only" by the `pyproject-fmt` pre-commit hook * Set `core-metadata-version = "2.2"` (copied from django-commons/django-debug-toolbar#1916) due to jazzband/help#360 * Didn't include the last 3 packages from the `packages` kwarg in `setup.py` when configuring `[tool.hatch.build.targets.wheel]`, since they don't make any difference in the generated wheel, as having just `simple_history` will include all its subpackages * As part of porting long_description's file concatenation from `setup.py`, `hatch-fancy-pypi-readme` was added to `requires` and configured to concatenate the same files - except with the first title of `README.rst` and the "Unreleased" section of `CHANGES.rst` removed (facilitated by the added "Start of PyPI readme" comments in those two files)

This was referenced Oct 24, 2022

Package management jazzband/help#313

Open

refactor!: poetry, github action overhaul, pyenv / asdf versions jazzband/django-robots#137

Closed

Update package metadata

12fa55c

ofek force-pushed the modernize-metadata branch from 4e855d0 to 12fa55c Compare October 24, 2022 03:41

matthiask reviewed Oct 24, 2022

View reviewed changes

hugovk approved these changes Oct 24, 2022

View reviewed changes

Update setup.py

1cf55d9

tim-schilling reviewed Nov 2, 2022

View reviewed changes

docs/contributing.rst Outdated Show resolved Hide resolved

Update contributing.rst

742e910

tim-schilling approved these changes Nov 2, 2022

View reviewed changes

matthiask merged commit 602f475 into django-commons:main Nov 2, 2022

ofek deleted the modernize-metadata branch November 2, 2022 20:04

hugovk mentioned this pull request Nov 2, 2022

Validate and format pyproject.toml #1700

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update package metadata #1690

Update package metadata #1690

ofek commented Oct 24, 2022

matthiask left a comment •

edited

Loading

hugovk left a comment

tim-schilling commented Oct 24, 2022

ofek commented Oct 24, 2022

matthiask commented Oct 24, 2022

ofek commented Oct 24, 2022

ofek commented Oct 25, 2022

hugovk commented Oct 25, 2022

tim-schilling commented Oct 27, 2022

matthiask commented Oct 28, 2022

ofek commented Oct 29, 2022

tim-schilling left a comment

matthiask commented Nov 2, 2022

pauloxnet commented Nov 2, 2022

ofek commented Nov 2, 2022

hugovk commented Nov 2, 2022

Update package metadata #1690

Update package metadata #1690

Conversation

ofek commented Oct 24, 2022

Background

Summary of changes

Notes

matthiask left a comment • edited Loading

Choose a reason for hiding this comment

hugovk left a comment

Choose a reason for hiding this comment

tim-schilling commented Oct 24, 2022

ofek commented Oct 24, 2022

matthiask commented Oct 24, 2022

ofek commented Oct 24, 2022

ofek commented Oct 25, 2022

hugovk commented Oct 25, 2022

tim-schilling commented Oct 27, 2022

matthiask commented Oct 28, 2022

ofek commented Oct 29, 2022

tim-schilling left a comment

Choose a reason for hiding this comment

matthiask commented Nov 2, 2022

pauloxnet commented Nov 2, 2022

ofek commented Nov 2, 2022

hugovk commented Nov 2, 2022

matthiask left a comment •

edited

Loading