fix: remove loopsolver/version.py resurrected by release-please - #315
Merged
Conversation
#314 deleted this file, but the release-please run triggered by that same merge re-created it with __version__ = "1.7.2" (LoopStructural's version, not loop_interpolation's real "0.0.1") before PR #313 was merged. Its own filename-search log line still showed the file as found on that run -- most likely GitHub's code-search index hadn't caught up with the deletion commit yet. Root cause: pointing the LoopStructural component's path at "." makes release-please's "find any file named version.py" search genuinely repo-wide rather than scoped to LoopStructural/, so it can collide with any version.py anywhere in the tree, present or future (e.g. the still-unmerged map2loop/loopstructural_visualisation packages each have their own). There's no release-please config to scope that search to a subpath, so the durable fix is having no other version.py files left for it to find. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Merged
lachlangrose
added a commit
that referenced
this pull request
Aug 14, 2026
…ject.toml instead of version.py Same fix as the LoopStructural root package: map2loop already had a static pyproject.toml version but its __init__.py still read from the now-redundant version.py; loopstructuralvisualisation had a dynamic pyproject.toml version resolved from its version.py via tool.setuptools.dynamic. Both now use a static pyproject.toml version directly, with map2loop's __version__ read via importlib.metadata at runtime (loopstructuralvisualisation's __init__.py never imported __version__, so no equivalent change needed there). Also drops loopstructuralvisualisation's release-please extra-files entry pointing at the now-deleted version.py. Done ahead of merging this PR: once merged, the root LoopStructural release-please component's repo-wide version.py filename search (a structural side effect of its path being ".", not scoped to a subdirectory) would otherwise find and try to bump these packages' version.py files too, colliding with their own release-please components -- the same bug fixed for loop_interpolation's stray loopsolver/version.py in #315.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
packages/loop_interpolation/src/loop_interpolation/loopsolver/version.pyas an unused stray file, but it came back: the release-please run triggered by fix: keep unprefixed v* tags for the LoopStructural release-please component #314's own merge re-created it with__version__ = "1.7.2"(LoopStructural's version, not loop_interpolation's real"0.0.1"from its ownpyproject.toml), and that landed onmasterwhen PR chore: release master #313 was merged.LoopStructuralcomponent's path to.(in fix: track LoopStructural version in pyproject.toml instead of version.py #312) made release-please's generic "find any file namedversion.py" search genuinely repo-wide instead of scoped toLoopStructural/. There's no release-please config option to scope that search to a subpath (checked the schema —exclude-pathsonly filters which commits count toward a release, not updater file targets). The safest fix is to make sure there are no otherversion.pyfiles left anywhere in the tree for it to find.masterstate is otherwise correct:pyproject.toml/manifest both at1.7.2,release-please-config.jsonstill has theinclude-component-in-tag: falsefix from fix: keep unprefixed v* tags for the LoopStructural release-please component #314.Heads up for later
The still-open workspace-package PR (map2loop / loopstructural_visualisation) adds its own legitimate
version.pyfiles underpackages/. Once merged, the same repo-wide search will find those too and may try to bump them to LoopStructural's version number, colliding withloopstructural_visualisation's own release-please component (which already manages itsversion.pyvia an explicitextra-filesentry). Worth addressing before that merge — likely by moving those packages offversion.pyin favor of a staticpyproject.tomlversion too, same as this fix did for the root package.Test plan
loopsolver.versionanywhere in the repo.masterpyproject.toml/manifest are correctly at1.7.2, unaffected by this fix.🤖 Generated with Claude Code