Skip to content

Simplify vcs version handling#119

Open
grst wants to merge 2 commits intomainfrom
vcs-versioning-fix
Open

Simplify vcs version handling#119
grst wants to merge 2 commits intomainfrom
vcs-versioning-fix

Conversation

@grst
Copy link
Contributor

@grst grst commented Feb 9, 2026

One downside of the VCS-based versioning is that when the project
is installed in editable mode, the version encoded in the package
metadata will remain the one from installation time and get stale.

There was some additional code in MuData that attempted to address this,
but I believe it does more harm than good:

  • while it would have updated __version__ (which is a convention, but
    not a standard), the standard way to retrieve the version via
    importlib.metadata would still have returned the version number
  • It goes hunting for the version number at import time and
    things can go wrong while doing so. In fact, building the conda
    recipe for scirpy fails on CI exactly because some dependency for
    getting the version at runtime is missing
    (https://github.com/scverse/scirpy/actions/runs/21799752388/job/62893203310?pr=672)
    or it might fail because one has a shallow clone without git history
    etc.

With this PR, I propose to get rid of all the additional version
handling and be more aligned with the cookiecutter template. Risking
stale metadata in editable mode is a trade-off that we conciously took
in the template, because the consequences are low-impact and only affect
developers.

One downside of the VCS-based versioning is that when the project
is installed in editable mode, the version encoded in the package
metadata will remain the one from installation time and get stale.

There was some additional code in MuData that attempted to address this,
but I believe it does more harm than good:
 * while it would have updated __version__ (which is a convention, but
   not a standard), the standard way to retrieve the version via
   importlib.metadata would still have returned the version number
 * It goes hunting for the version number at import time and
   things can go wrong while doing so. In fact, building the conda
   recipe for scirpy fails on CI exactly because some dependency for
   getting the version at runtime is missing
   (https://github.com/scverse/scirpy/actions/runs/21799752388/job/62893203310?pr=672)
   or it might fail because one has a shallow clone without git history
   etc.

With this PR, I propose to get rid of all the additional version
handling and be more aligned with the cookiecutter template. Risking
stale metadata in editable mode is a trade-off that we conciously took
in the template, because the consequences are low-impact and only affect
developers.
@grst grst requested a review from ilia-kats February 9, 2026 08:25
@codecov
Copy link

codecov bot commented Feb 9, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.50%. Comparing base (b047610) to head (129aa29).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #119      +/-   ##
==========================================
- Coverage   68.57%   68.50%   -0.08%     
==========================================
  Files          12       11       -1     
  Lines        1906     1889      -17     
==========================================
- Hits         1307     1294      -13     
+ Misses        599      595       -4     
Files with missing lines Coverage Δ
src/mudata/__init__.py 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

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.

1 participant