Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(fix): add __version__ #40

Merged
merged 4 commits into from
Nov 18, 2024
Merged

(fix): add __version__ #40

merged 4 commits into from
Nov 18, 2024

Conversation

LDeakin
Copy link
Collaborator

@LDeakin LDeakin commented Nov 16, 2024

No description provided.

Copy link
Owner

@ilan-gold ilan-gold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We haven't settled on a release process, but I think when you do releases with git tags, there is a _version.py that is updated automatically. Phil definitely knows more than I do about this.

i.e., https://github.com/scverse/anndata/blob/af6480e44a3fa84b7c2dc7195e59d2ce443b06d0/src/anndata/__init__.py#L13

I believe this is done via hatch-vcs

@LDeakin
Copy link
Collaborator Author

LDeakin commented Nov 16, 2024

Ok, we'll need to tie that in with Maturin in some way. I think the single source of truth is currently the Cargo.toml

@ilan-gold
Copy link
Owner

https://docs.python.org/3/library/importlib.metadata.html#importlib.metadata.version It's possible this somehow works magically, but I honestly don't know (and probably have no way of knowing from that docstring)

Copy link
Owner

@ilan-gold ilan-gold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I should have just tried this. It does work, and must be coming from the build process but don't really understand how.

@flying-sheep
Copy link
Collaborator

importlib.metadata.version() gets the version from an installed package’s metadata. It uses the import machinery to find the installed package’s “.dist-info/METADATA” file that contains all metadata like name, version, license, dependencies, …
So once you hatch run ... or maturin develop or pip install -e ., you get a special “editable” version of your package+metadata installed into a virtualenv. And calling importlib.metadata.version() inside of the package, the code is executed from that venv where it’s installed, and doing so finds that metadata and returns its value.

To explain everything else:

To build a Python package, one needs a build backend.
We currently use maturin directly as a build backend.
Having VCS versioning requires the build backend to support that.
Maturin doesn’t, and currently you can’t use maturin as a plugin for another build backend (PyO3/maturin#1419), so you can’t leverage their capabilities (e.g. VCS versioning)

So we currently can’t do that. But:

Maturin derives the Python package’s version number from Cargo.toml. And for Rust packages exists very nice relase automation in the form of release-plz.

@LDeakin
Copy link
Collaborator Author

LDeakin commented Nov 16, 2024

Since it all depends on the Cargo.toml package version anyway, I changed this to just use the CARGO_PKG_VERSION. This is what polars does.

@flying-sheep
Copy link
Collaborator

flying-sheep commented Nov 18, 2024

That’s 300μs faster at import time which is nothing. But since it’s also not complicated either is fine.

@flying-sheep flying-sheep merged commit a36e087 into main Nov 18, 2024
1 check passed
@flying-sheep flying-sheep deleted the ld/module_version branch November 18, 2024 08:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants