Use standard API for version information

[flying-sheep]

Please describe your wishes and possible alternatives to achieve the desired result.

In our code, we access something.__version__ in multiple places.

This is a convention, but a standard API exists for this metadata: importlib.metadata.version('something'). We should use that.

We already do that in scanpy, almost everywhere: https://github.com/scverse/scanpy/blob/e00932b6d5b1694d7706b36a0dc604aa2c27d885/scanpy/_compat.py#L69-L73

[flying-sheep]

OK, summary of @ivirshup’s and my discussion:

There are some rare cases that require jumping around between commits in editable installs so much that .__version__ and version() disagree in a significant way. E.g. @ivirshup sometimes debugs something in both an upstream and then a downstream library with both being editably installed so he can quickly git switch between versions. Then he makes a PR from one of these repos. During this process the discrepancy can get so big that apparently some version checks in some librarly can get affected and result in different code paths.

Since there are projects relying on either (or in case of scanpy, both) APIs for version checks, and packages that don’t have .__version__, the situation is already broken: One can’t rely on anything working, even if all our projects use .__version__ exclusively where possible.

Resolutions:

• I continue working on https://github.com/flying-sheep/session-info2 which will be able to show when there’s a discrepancy.
• I ask if someone’s interested in writing a PEP in https://discuss.python.org/t/dynamic-versions-in-editable-installations/15220/26
• If there’s no progress in that discussion, we will focus on some developer-side solution (because as said, the situation is already broken, so there would have to be something facilitating workflows like the above)

@ivirshup did I get that all right?