Specifying __version__ using __import__("importlib.metadata") ?

[consideRatio]

@bollwyvl made me aware about a strategy to specify __version__ in a way that I've not seen us do in any jupyterhub org package through jupyterhub/jupyter-server-proxy#427 (review).

Currently:

# __version__ should be updated using tbump, based on configuration in
# pyproject.toml, according to instructions in RELEASE.md.
#
__version__ = "4.1.1-0.dev"

With @bollwyvl's suggestion:

__version__ == __import__("importlib.metadata").metadata.version("jupyter_server_proxy")

Is this robust enough to use systematically, reducing the complexity of what tbump or any other tooling is required to accomplish? Should we systematically transition towards this pattern?

[bollwyvl]

To further expand: ultimately, the complexity is finally removed when there is exactly one source of truth which the python build system and runtime pull from, using only stdlib.

Regarding hatch-nodejs-version in specific: package.json is a good source of truth, as it is fully static, which means you can look across all the millions of package versions on npm and fully rely on them having (valid) version numbers that have been preserved, unchanged, from the source repo. The same cannot be said for PyPI. It is a pity, indeed, that canonical pre-release version strings aren't compatible between pypi and npm. In the case of pyproject.toml and package.jsons, I've found just testing these two values for equivalence, modulo some transformation, gives good enough quality control, vs big rube goldberg contraptions. Heck, during test, i'd pay dearly for something that validated the version, by no-fooling looking at types, etc. to see if a breaking change happened.

Just don't use versioneer 😆

[manics]

Just don't use versioneer 😆

I use setuptools-scm for my (non-js python) projects 🤣

[minrk]

I think tbump works well, and taking an approach like this doesn't solve a problem that we currently have. I think it's a fine approach to take, but since tbump takes care of it already while also covering the tagging & publishing workflow, it's adding dynamic logic that might be sensitive to unusual things like importing based on PYTHONPATH without installing, etc. where we currently have a simple string that always works.

I use setuptools-scm

I think importlib-metadata is probably a great pair for setuptools-scm, and it even recommends taking this approach, since it's how you have __version__ in sync with what setuptools-scm produced without any build-time steps.

[manics]

@consideRatio Could you say a bit more about the advantages of importlib.metadata? It sounds like it's good when the version is dynamically set, but what are the advantages when it's statically set (by tbump, or anything else)?

[consideRatio]

@consideRatio Could you say a bit more about the advantages of importlib.metadata? It sounds like it's good when the version is dynamically set, but what are the advantages when it's statically set (by tbump, or anything else)?

I don't advocate the approach if there is any possible issues, as tbump does a good job for us handling this. But the minor benefit I see is that our pyproject.toml's configuration of tbump no longer needs one specific entry.

I think tbump works well, and taking an approach like this doesn't solve a problem that we currently have. I think it's a fine approach to take, but since tbump takes care of it already while also covering the tagging & publishing workflow, it's adding dynamic logic that might be sensitive to unusual things like importing based on PYTHONPATH without installing, etc. where we currently have a simple string that always works.

I agree with this thought overall - should we go for a close?