patrick-kidger
Introduce automatic versioning for pre-release usage
Currently the version number 0.0.8 is hardcoded in pyproject.toml meaning that if I install from the main github branch pip will tell me I have installed 0.0.8 even though it differs from the version on PyPi. If I already have the PyPi version installed I'm not even sure pip will reinstall as it thinks I am up to date.
This can be solved using automatic versioning tools such as hatch-vcs which bases versions solely on GitHub tags, e.g.:
[project]
...
dynamic=["version"]
[build-system]
requires = ["hatchling", "hatch-vcs", "toml"]
build-backend = "hatchling.build"
[tool.hatch.version]
source = "vcs"
[tool.hatch.build.hooks.vcs]
version-file = "lineax/_version.py"
Hmm, I think I'm inclined not to do this just to avoid complicating what is currently a nicely simple build system. I definitely see the value, I just don't think it's so much that I want to handle the extra 2 hours worth of work it'll take me to debug some edge case in this later :)
That said, I am concious that the new tridiagonal work is in and you're probably looking to use that! We could do a new versioned release if you like?
Completely understand, thought it was useful to highlight the behaviour by pip here to weigh up trade-offs. Feel free to close or leave for reference as you prefer. Another option I guess is just to manually rename to 0.0.8dev on the first commit after a release. I've actually worked out how to use the new tridiagonal work (just got caught out by the pip issue initally) so don't let that have an outsized impact on your criteria for pressing a new release, can confirm it's provide nice speedups on CPU and crazy speedups on GPU! 🚀