Try replacing setup.* with pyproject.toml
#144
Conversation
|
I was just thinking of dipping a toe back in here, starting with this. May I toss some commits here on the versioneer aspect? |
|
Dan!! Absolutely, please do add some commits |
|
I was just reading through the PRs that went into v0.29 of Versioneer and python-versioneer/python-versioneer#371 makes it sound like maybe |
|
Hello! It's been too long! If I recall correctly, we based this repo on a template and set of recommendations that I used to work from for most of my projects. In May, I got together with Henry Schreiner for week, and we produced updated recommendations. We cover four build backends, including setuptools, but I've been moving my projects over to hatchling and the hatch-vcs extension in place of versioneer. Its builds are isolated. I've been happy with the git integration. In addition to versioning, it uses If that sounds reasonable I'll push some commits to try that on here. |
|
@danielballan that sounds pretty reasonable to me! (I think last time I was playing with newer Python tools, I liked PDM more than Hatch, but that was mainly because I didn’t think Hatch managed venvs, and it looks like that’s either changed or I understood it wrong back then. I also liked that it did PEP 582, but that got killed and I am sad.) One question about Python versions, though: We currently support Python 3.6, and I think Hatch/Hatchling are 3.7+ (I guess the latest Hatchling looks like just 3.8+). I think the IIRC we support 3.6 here because Google Colab took a long time to update, but I just checked and it looks like Colab is on Python 3.10 now. So it’s probably OK to change our minimum Python version. Just want to flag it as a breaking change to avoid if it’s not too hard. |
|
Good note. Python 3.6 reached end-of-life (no more security patches) in 2021. Python 3.7 reached end-of-life in June 2023. I've been in the habit of dropping Python versions from the test matrix once they are end-of-lifed. Naturally, users stuck on all versions can resort to using older releases of Would that policy create a problem for known users? |
|
In the ~5 years it's been since I showed my face here, my commit bit went away (which is very reasonable). I started a PR into this branch over on my fork: #145 |
|
Do you want it back? I’m happy to add you as a committer/maintainer/admin (depending on how responsible you want to be 😉). |
|
Thanks. Let’s give it a couple months and see if I manage to stay active. 🙂 |
Starting an experiment in all project description and definition to `pyproject.toml`. It *seems* robust enough to handle it all now.
Mr0grog
force-pushed
the
can-we-drop-setuppy-lets-find-out
branch
from
30e4243 to
e891218
Compare
pyproject.toml
Outdated
| # FIXME: how does this show up in PyPI? In setup.py we had: | ||
| # license="BSD (3-clause)" | ||
| # But that's not the right format here. And there's no trove classifier for it. | ||
| # Maybe this should be: | ||
| # license = {text = "BSD (3-clause)"} | ||
| license = {file = "LICENSE"} |
There was a problem hiding this comment.
Yeah, this should probably change. Here’s how the the file reference shows up on test.pypi.org:
vs. what we currently have with setup.py:
There was a problem hiding this comment.
Changed this and uploaded to test.pypi.org; it fixes the issue!
Also remove TODO that has been addressed about the `readme` reference.
|
Yowza, this dropped 3,025 lines of code! Granted that was mostly Versioneer, but nice to see it go. 👋 |
| node: $Format:%H$ | ||
| node-date: $Format:%cI$ | ||
| describe-name: $Format:%(describe:tags=true,match=*[0-9]*)$ | ||
| ref-names: $Format:%D$ |
There was a problem hiding this comment.
@Mr0grog FYI it was later determined that having ref-names is problematic, and it's no longer recommended to include it into this template: https://setuptools-scm.rtfd.io/en/latest/usage/#git-archives / pypa/setuptools-scm#1033.
There was a problem hiding this comment.
Ah, that is interesting, thanks very much. I’ll pull it out of the main development branch. 🙇
That said, please post things like this as a new issue (or an existing open issue if applicable) rather than re-opening discussion on a completed PR in the future. It makes it a little easier to track things that need to get done (and attribution for release notes). 🙂
There was a problem hiding this comment.
Yeah, it was more of a drive-by discovery, a thing that I noticed in passing so I put a comment where some context exists. I'm not a user of this project, but when I notice something in places I visit while doing git paleontology, and don't have time to spend on writing a long explanation, this seems like an acceptable middle ground :)
It turns out the way we populated the `ref-names` field causes its value to change depending on whether the commit a Git archive was built from was the head of a branch when it was built (which is often true when we first cut a release, but ceases to be true soon afterward. If someone downloads an archive *later* and tries to compare its signature with the one we released, it won’t match because this field has changed, and that’s a significant issue. Unfortunately, there’s no good alternative that resolves this issue, so the best solution is to just remove the field. On the up-side, `describe-name` carries the more critical info about the the current tag or release version, so this isn’t a huge loss. Thanks to @webknjaz for pointing this out: #144 (comment)
It turns out the way we populated the `ref-names` field causes its value to change depending on whether the commit a Git archive was built from was the head of a branch when it was built (which is often true when we first cut a release, but ceases to be true soon afterward. If someone downloads an archive *later* and tries to compare its signature with the one we released, it won’t match because this field has changed, and that’s a significant issue. Unfortunately, there’s no good alternative that resolves this issue, so the best solution is to just remove the field. On the up-side, `describe-name` carries the more critical info about the the current tag or release version, so this isn’t a huge loss. Thanks to @webknjaz for pointing this out: #144 (comment)
Direct usage of
setup.py(that is callingpython setup.py some_commandto do builds and such) has been deprecated and no longer supported for quote a while, and I’ve been meaning to try to move everything topyproject.toml(the new format for declaring package metadata). It seems likepyproject.tomlsupports all the nice things now, so this is my experimental attempt to switch to it and dropsetup.pyandsetup.cfgentirely.(This seems like a good time to do this, since there are some other semi-breaking changes on tap, like rethinking how rate limit errors are handled.)
This doesn’t quite work yet — the main sticking point is Versioneer. When
piporbuildtry and make an isolated environment, it’s missing the runtime requirements for the package and can’t import the version from the code.This might be fixable by:
_build_version.pyfile that pulls in the version info the same as__init__.pydoes but without requiring any other dependencies.setup.pyjust to run Versioneer. (But it seems like this shouldn’t be necessary since Versioneer 0.29 claims support forpyproject.toml-only build systems: https://github.com/python-versioneer/python-versioneer/releases/tag/0.29)Need to experiment here.
Obviously this will need CI changes and maybe Dependabot config, too.
Also Needs testing to make sure builds based on this are still installable and workable on Python 3.6 (assuming a recent version of pip is being used to install).