Write version file with `setuptools-scm`

[daskol]

Package version in flax.version is not updated properly on regular basis. This results in impossibility to make a wheel out out git repo (e.g. SETUPTOOLS_SCM_PRETEND_VERSION=0.7.1 python -m build -nw .). This commits enables setuptools-scm to read configuration from pyproject.toml and configure version file.

@chiamp Some packaging issues related to the latest release 0.7.1 are solved in this PR.

[PhilipVinc]

I strongly suggest merging this as well. Getting the version wrong becomes impossible after this.

BTW, This will break the current conda-forge recipe, but can be easily fixed.

[daskol]

@PhilipVinc I can't find a conda recipe. Could you share a link to it?

[PhilipVinc]

It's here https://github.com/conda-forge/flax-feedstock but don't worry, I'll do it myself.

[daskol]

@chiamp Any comments about "new" 0.7.1 release? Do you understand that all vendored flax packages of version 0.7.1 should be rebuilt with new checksums and reinstalled, patches should be rolled back, all artifacts should be recreated, caches should be cleared, and so on? Please, never change release tags and do not forget to update flax.version.__version__ and changelog.

[chiamp]

hi @dasklol, could you clarify what you mean by "never change release tags"? Every time a release is published, the tag gets updated to reflect the new version number.

[PhilipVinc]

I think what he means is that after you tag a commit with a certain version (eg 0.7.1) you should not delete this tag and tag a new commit with the same version (eg 0.7.1).

(If you get a release wrong, the PyPi way would be to tag a new version 0.7.1.post1 and ideally also yank the previous release)

I'm not sure but maybe something like that happened after you tagged 0.7.1 (I think originally you did not update the internal version file...?)

[daskol]

Thanks @PhilipVinc. You precisely expressed my thoughts.

I'd like to add that a version (and a version tag) is a kind of a public contract which you as a maintainer is voluntarily obliged to follow. The contract says that anyone at anytime can get exactly the same tarball of source files. There are a lot of tools which is assumed this invariant.

I'm not sure but maybe something like that happened after you tagged 0.7.1 (I think originally you did not update the internal version file...?)

The initial release 0.7.1 was 3741278de6427e61f93b7958ac20b5d224c1886b then fix at commit 3741278de6427e61f93b7958ac20b5d224c1886b was merged and published as 0.7.1 again. This broke pipelines due to multiple reasons (checksum change and tarball cache) and affected several users.

@chiamp By the way, what is actual reason to have flax.version.__version__ and manually bump it on release? Is it somehow related to Google's internals?

[IvyZX]

On the mistaken 0.7.1 release, no PyPI package was built and uploaded because the version check did not pass. And since it didn't really impacted PyPI, it shouldn't be a big problem to delete and re-build a 0.7.1 release. Is there any specific issue you ran into?

By the way, what is actual reason to have flax.version.__version__ and manually bump it on release? Is it somehow related to Google's internals?

Yes - we bump the HEAD version (e.g., with the last release being 0.7.1, the head version.py gives 0.7.2) because of Google's internals. JAX also follows this pattern.

[levskaya]

Apologies for the trouble - earlier we cut a 0.7.2 release and yanked the old 0.7.1 release to remedy the issue.