jwcrypto
jwcrypto copied to clipboard
latchset
Migrate from setuptools/tox to hatch
More and more packages are migrating to more modern build/env tooling, and one of those tools is hatch. It can replace both setuptools and tox here, and it's also the one used in the official PyPI guides. Interestingly, even tox itself is migrating to hatch for their rewrite
Before I invest the time of creating a PR for this, would this be something you're interested in?
Yeah, that takes care of the setuptools part, but it still requires some manual work (did it out of curiosity and the version detection and license name both needed some adjustment) and doesn't take care of the bigger/more complicated task of migrating the tox envs into hatch as well.
Oh, and not to mention migrating the stuff from the Makefile into hatch as well.
Ok I do not know hatch, so I would like to know a few things:
- What are the advantages of migrating
- What are the disadvantages of migrating
- What is the maturity level of hatch
- What platforms would I leave behind migrating to hatch
For some of those questions, @ofek is surely better qualified to answer, but considering I started this I'll answer to the best of my knowledge and @ofek can jump in if I get anything wrong.
- advantages of migrating: I find hatch nicer to use than the plethora of tools it replaces. Having one tool with all the batteries included, like it's common for other languages (think npm and cargo for example), makes working on repositories quite a bit easier IMO. But that's kinda personal preference. In general, as mentioned in the OP, hatch is tooling by the same group as setuptools (namely the Python Packaging Authority), but it's just a way more modern piece of software, and as such is now being used in examples on packaging.python.org all over the place.
- disadvantages of migrating: Contributors (and maintainers) need to adjust their workflows accordingly. Instead of
make,tox,python setup.pyetc, they'll have to run the hatch equivalent. Can't really think of other disadvantages here. My interactions with hatch (both from my perspective as someone packaging python software for a Linux distribution, as well as from the perspective of a library developer publishing software to pypi.org and running tests, linting etc) have been extremely smooth. - maturiry: As an official PyPA project, which is following semver and has had a 1.0.0 release in the past, I think it can be considered production ready. https://github.com/pypa/hatch/blob/master/pyproject.toml#L26 agrees with that, and the adoption over at https://hatch.pypa.io/latest/users/ kinda speaks for itself as well. Quite a few big projects are adopting it, and again, as already mentioned in the OP, even tox is migrating to it for their rewrite, at least on the build backend side of things.
- platforms left behind: I think for developers of jwcrypto, this means that python 3.6 can't be used anymore, I think for users it doesn't change anything, but I'm not 100% sure on that. 3.6 is EOL anyway though, so I think that doesn't matter much.
Anything I forgot to mention, @ofek?
What platforms would I leave behind migrating to hatch
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.
Considering I recently change the code to: python_requires = '>= 3.6' it sounds like not a huge deal to move to >= 3.7
If this is "the way of the future", who am I to stand in the way ?
I would definitely review a PR.
As for the Makefile, it would be nice to preserve the targets that can be preserved, it is my way to re-learn how to run the various python tools (in this case will be how to use hatch) when I stay a way for long enough to forget.
Considering I recently change the code to: python_requires = '>= 3.6' it sounds like not a huge deal to move to >= 3.7
I'm not sure this is necessary for users installing the library, just for building it, but maybe @ofek can clarify this bis?
As for the Makefile, it would be nice to preserve the targets that can be preserved, it is my way to re-learn how to run the various python tools (in this case will be how to use hatch) when I stay a way for long enough to forget.
So that'd be a Makefile wrapping hatch basically? Because I'd prefer to have the commands for testing, linting etc in a document instead, but I can surely also add a Makefile if you want it.
Yes the Makefile is just a muscle-memory convenience, I am totally for a Doc as well.
I'm not sure this is necessary for users installing the library, just for building it
Correct
JFTR, it is the building on older distributions that gives me pause, but I do not know if 3.6 is an important version, in that sense, or not.
Cool stats, seem lion share is 3.7 in terms of downloads, but that counts only pypi.
Such environments are unlikely to be using new versions of libraries anyway so they'd never hit this
I haven't been able to work on this yet, because I've had other more urgent stuff to work on. I still plan on working on this though, unless someone else is quicker of course. I'll update this issue when I actually start on it :)