deps: Re-resolve pixi.lock, and stop tracking generated version.py

[wwood]

Why

pixi update was unsolvable on main:

Because singlem==0.21.4 depends on tqdm==4.67.3 and tqdm==4.70.0, we can
conclude that singlem==0.21.4 cannot be used.

admin/requirements.txt was committed with the pins generated during the v0.21.3 release, and pyproject.toml feeds that file to setuptools as [project].dependencies. So the editable local package demanded tqdm==4.67.3 while the fresh conda solve wanted 4.70.0. .gitignore already says this file is "tracked as a stub"; it is now actually a stub again. The pinned version is still generated by admin/build_dep_defs_from_pixi.py locally at release time and in CI before the wheel build.

Dependency updates

diamond 2.2.0 → 2.2.6, smafa 0.8.0 → 0.9.0, polars 1.40.1 → 1.44.1, pyarrow 24 → 25, sqlalchemy 2.0.49 → 2.0.52, sqlparse 0.5.5 → 0.6.0, tqdm 4.67.3 → 4.70.0, biopython 1.87 → 1.88, bird_tool_utils 0.6.0 → 0.7.2, numpy 2.4.4 → 2.5.3, python 3.12.13 → 3.12.14, plus the usual pile of transitive conda rebuilds. pixi.toml is unchanged.

Ported from dev

pyproject.toml and singlem/__init__.py are now byte-identical to origin/dev, taking 707c1f8 and the non-lock half of 6e3c5cf:

• singlem/__init__.py reads the version from importlib.metadata, falling back to .version
• version_file dropped from [tool.setuptools_scm], version_scheme → guess-next-dev
• singlem/version.py is no longer tracked

Dev's pixi.lock was deliberately not cherry-picked — it is a re-lock from 2026-06-27 (diamond 2.2.2, smafa 0.8.0) that would undo the fresh resolve, and dev's pixi.toml carries unreleased-feature deps (weebill, duckdb, numpy, scipy) that do not belong on main.

Two fixes dev does not have

Untracking version.py breaks the release path unless these come with it:

• admin/release.py: --force-write-version-files now writes nothing, so the following git commit -a -m "vX" would exit non-zero with nothing to commit. The tag is applied to the already-clean HEAD instead. Also git checkout -- admin/requirements.txt after the generator runs, otherwise the regenerated pins fail the "repo is clean" check and get re-committed — which is exactly how this breakage arrived.
• .github/workflows/publish-to-pypi.yml: fetch-depth: 0, since the wheel version now comes from git describe rather than a committed version.py, and actions/checkout@v2 clones at depth 1.

Testing

• pixi run -e dev pytest test → 224 passed, 25 skipped in 10m33s
• pixi lock --check → up to date
• pixi run singlem --version and pixi run lyrebird --version → 0.21.5.dev0 (guess-next-dev on a dirty post-v0.21.4 tree; a clean tag build gives the plain version)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f16ca0a19

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep a usable fallback for source-tree imports

When SingleM is imported from a clean source checkout without installed distribution metadata, _pkg_version("singlem") raises PackageNotFoundError, but this handler then imports the now-deleted singlem.version, so the package fails with ModuleNotFoundError; this also breaks every Python 3.7 import because importlib.metadata is unavailable despite requires-python = ">=3.7". Retain a version module or derive the fallback version without requiring installed metadata.

Useful? React with 👍 / 👎.

[wwood]

Confirmed and fixed in 0e58bf3.

Reproduced on a pristine clone with an interpreter that has no singlem installed:

File "/tmp/cleanclone/singlem/__init__.py", line 6, in <module>
    from .version import __version__
ModuleNotFoundError: No module named 'singlem.version'

Worth noting it only bites on a clean checkout — importlib.metadata scans sys.path entries for *.egg-info/*.dist-info, so any source tree that has ever been built resolves the version from the leftover singlem.egg-info and hides the bug. That is why it was not obvious.

Fixed by dropping the import of the deleted module rather than reinstating it, since setuptools_scm no longer writes singlem/version.py:

except (ImportError, PackageNotFoundError):
    __version__ = 'unknown'

This also covers the python <3.8 branch you raised: previously that path crashed, now it degrades to 'unknown'. Same pristine clone now imports cleanly and reports unknown, while pixi run singlem --version still reports 0.21.5.dev0 from the editable install's metadata.

On requires-python = ">=3.7": that is stale independent of this PR — the resolved stack (polars 1.44, pyarrow 25, numpy 2.5) needs ≥3.9, and pixi resolves python 3.12. Leaving it for a separate change rather than widening this PR's scope.