Update package metadata #1690
Update package metadata #1690
Conversation
ofek
force-pushed
the
modernize-metadata
branch
from
4e855d0
to
12fa55c
Compare
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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?)
|
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. |
Not a complete list but here's from a recent comment - Hatchling:
Can I remove it? |
Thanks!
I think it probably makes more sense to copy urllib3 there as well? See community/community#6456 |
|
Done! |
Can we do that in a separate PR? |
|
Sure! |
|
@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? |
|
@tim-schilling I think it's fine to batch it. We can always push another release or revert in the worst case. |
|
another just merged prettytable/prettytable#212 |
There was a problem hiding this comment.
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.
|
Me neither, let's merge it then. Thanks all! |
|
Great. Can we create a recipe with steps to apply this update in other jazzband packages ? |
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)
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.pyfiles 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, andMANIFEST.in. The build backendhatchling(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
debug_toolbar/__init__.py, removing a release step*.egg-infofrompython setup.py develop; this is now fixedsetup.py, I followed https://github.com/urllib3/urllib3/blob/main/setup.pypypa/gh-action-pypi-publishAction https://github.com/pypa/gh-action-pypi-publish#-master-branch-sunset-