Write version in pyproject toml if available #401
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
reinout
reviewed
Feb 8, 2023
See https://snarky.ca/what-the-heck-is-pyproject-toml/ I probably do not understand enough of this yet...
The writing of the version works, which is the main thing I wanted to fix. But currently zest.releaser only creates an sdist and wheel if there is a `setup.py` file. In that case it runs `python setup.py sdist`, etc. So there is room for improvement. In the new test, I use the tha.example package, remove `setup.cfg` and `setup.py`, and add a `pyproject.toml`. I compiled this file with help from `pdm`. See also https://pdm.fming.dev/latest/usage/cli_reference/#exec-0--import Roughly: - Extract the example.tar and copy it somewhere. - In that directory do git init and commit everything. - Do `pipx install pdm`. - pdm init - pdm add setuptools # otherwise you get an error in the next step - pdm import setup.py - Then you can look at the generated pyproject.toml. It is a basis, but you may need to change stuff. I did not want a big file, so I removed a lot of lines. Easiest way that I found to check the result, is to call `pyroma .` You should first remove `setup.cfg` and `setup.py` of course. Well, you can also combine two or three of these files. I think for a package with only `pyproject.toml` you need at least `setuptools` 61. Just thinking out loud: For Plone projects, and perhaps also zest.releaser, it may be best to: - Translate imperative setup.py to declarative setup.cfg. So keep using setuptools for now. - Add a pyproject.toml and specify setuptools as the build system: ``` [build-system] requires = ["setuptools>=61", "wheel"] build-backend = "setuptools.build_meta" ``` Maybe without minimum version.
Python 3.6 tests fail with:
ERROR: No matching distribution found for setuptools>=61
And we do seem to need that in this new test with pyproject.toml only.
Python 3.6 is out of support of the Python community anyway.
See https://github.com/zestsoftware/zest.releaser/actions/runs/4127226730/jobs/7130170595
In setup.py this used compatibility code for Python 2, and encoding fallbacks, which are ugly, pyproject.toml cannot handle multiple files, as far as I can see. setup.cfg happily does this.
|
Okay, so I added a test, and it works fine. The message from the commit may be interesting: 1bd1315. Problem: the test does not work on Python 3.6, so I dropped support for that. We will want to make a major release for this. I think the current PR is fine to merge: it enables updating the version when it is in |
|
I agree. I'll merge it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
pyproject.tomland moved most metadata there. "Eat your own dog food." I am not sure if we can get rid of the remaining parts ofsetup.py.tomlito the dependencies on Pythons earlier than 3.11. Chances are that you already have this via a different dependency. On 3.11 I use the built-intomllib.setup.pyor other files.bin/prereleaseupdates the version in our ownpyproject.toml. I did not commit this.This fixes issue #373.