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.
lachlangrose
added a commit
that referenced
this pull request
Aug 17, 2026
…ce (#303) * fix: Updating intrusions code - Added a new method `_validate_intrusion_inputs` in `GeologicalModel` to validate inputs for intrusions, ensuring necessary data is present before processing. - Updated `_build_intrusion` to call the new validation method, improving error handling for missing data. - Refactored `IntrusionBuilder.create_geometry_using_geometric_scaling` to clarify that geometric scaling is not currently implemented, raising a `NotImplementedError` immediately. - Simplified threshold handling in `IntrusionFeature` by removing redundant checks for marginal faults. - Removed the unused `intrusion_support_functions.py` file to clean up the codebase. - Updated tests in `test_intrusions.py` to cover new validation logic, ensuring clear error messages for missing data and parameters. - Added regression tests for previously silent errors related to weight handling and geometric scaling. (cherry picked from commit 8cb80c1) * feat: add loopstructural-visualisation as packages/loopstructural_visualisation workspace package Ports the loopstructural-visualisation repo in as a uv-workspace member, following the src-layout pattern proven by packages/loop_common and packages/loop_interpolation in Stage 2. Import name stays loopstructuralvisualisation; only the on-disk container path changes. - Routed the one print() call in __init__.py's trame-ui import guard through LoopStructural.utils.getLogger, consistent with the rest of the ecosystem's logging conventions. - Left LoopStructural.datatypes imports in _3d_viewer.py as-is rather than swapping to LoopStructural.geometry: that module only exists in this repo's unreleased dev tree, not in any published LoopStructural release, and the package's declared floor is LoopStructural>=1.6.17. (cherry picked from commit 07f0868) * feat: add map2loop as packages/map2loop workspace package Ports Loop3D/map2loop (upstream commit 078f8a6, master @ 3.3.1) into this repo as packages/map2loop, following the packages/loop_interpolation src-layout convention (Stage 2 of ROADMAP.md), for Stage 4's map2loop half. - Source moved from flat map2loop/ to src/map2loop/; test suite ported to packages/map2loop/tests/ unchanged apart from one CWD-relative fixture path fix (tests/sampler/geo_test.csv -> path relative to the test file) needed because tests now run from the monorepo root, not map2loop's own repo root. - pyproject.toml written from the loop_interpolation template (build system, classifiers, src-layout packages.find, tests extra) but keeps map2loop's own real name/version/requires-python/dependencies. - Dependency-declaration gaps fixed (imported at module level but undeclared upstream): pandas and packaging. GDAL (osgeo) is also a hard, module-level import but is deliberately left undeclared, matching upstream's own convention of treating it as an externally-provisioned (conda/system) dependency rather than a pip one -- their own dependencies.txt explicitly skips it in check_all_dependencies(), and pip-building it from source fails without system libgdal headers. - dependencies.txt (consulted at runtime by map2loop's own import-time version-compatibility self-check) copied to src/dependencies.txt to match the relative path the existing code resolves it from, and pytest removed from it since map2loop's own self-check otherwise hard-requires pytest to be installed for a plain (non-tests-extra) install to import successfully. Verified in an isolated uv venv: `import map2loop` succeeds, and `pytest packages/map2loop/tests` gives 78 passed, 4 failed, 1 skipped, 1 collection error -- all 5 non-passing outcomes trace back to the absence of native GDAL bindings in this pip/Windows-only verification environment (4 of them) or a monorepo-embedding artifact where one test's internal `pytest.main()` call with no explicit path picks up this repo's own unrelated tests/conftest.py pytest_plugins (1 of them), not to the port itself. Audited for loop_common type reuse per ROADMAP.md Stage 4: no swap made. map2loop's bounding_box is a plain dict of map-CRS extents threaded through dozens of call sites, architecturally unrelated to loop_common.geometry.BoundingBox's local/global mesh-frame transform model; its own map2loop.logging module is already map2loop's public, already-used API surface, so routing its handful of ad-hoc print() statements through loop_common.logging would need adding loop-common as a new hard dependency for a cosmetic swap; no custom point/orientation data structures exist to compare against loop_common.observations (dip/dip direction data stays as GeoDataFrame columns throughout). No clean, low-risk win found. (cherry picked from commit fb755cc) * feat: wire map2loop and loopstructural_visualisation into the workspace Completes Stage 4 (ROADMAP.md, outcomes 5/7) for map2loop and loopstructural-visualisation, following on from the two ported packages already merged in from agent worktrees (packages/map2loop, packages/loopstructural_visualisation). - Add both to [tool.uv.sources]; loopstructural_visualisation also needs LoopStructural = { workspace = true } since it depends on LoopStructural itself, which uv treats as an implicit workspace member once referenced by name. - CI: loopstructural_visualisation joins the existing packages-test matrix; map2loop gets its own ubuntu-only job (map2loop-test) with an apt-installed libgdal, since GDAL has no pip wheel on Windows/macOS and upstream map2loop itself only tests via conda for the same reason. - Add a minimal import-smoke test for loopstructural_visualisation, which shipped with zero test coverage upstream. - Wire both into pypi.yml sdist/publish, release-please-config.json + .release-please-manifest.json (loopstructural_visualisation uses extra-files to bump version.py's __version__, since it has no static pyproject version field), and grandfather D/ANN ruff rules for both (matching the loop_common/loop_interpolation precedent). - Correct ROADMAP.md: loopresources (Stage 4a) was never actually merged to master, despite a prior status-log entry claiming otherwise. Verified: uv sync resolves cleanly for both packages standalone and as a full workspace sync; tests/unit 695 passed/4 skipped (zero regressions). (cherry picked from commit ce71cae) * fix: track map2loop and loopstructuralvisualisation versions in pyproject.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. * fix: register map2loop in tool.uv.sources Missing alongside loopstructuralvisualisation/LoopStructural, causing the same uv workspace-member/sources mismatch build failure for the map2loop package. * ci: fix matrix package names * ci: split package name from directory in packages-test matrix uv --package matches on the declared pyproject.toml name, which for loopstructuralvisualisation has no separator, while its directory under packages/ uses an underscore. A single matrix.package string can't satisfy both the uv --package flag and the pytest path, so track name and dir separately. * ci: fix map2loop gdal_array import by disabling build isolation for gdal pip/uv build gdal's sdist in an isolated env by default, so its setup.py can't see the numpy already installed in the synced venv and skips compiling the _gdal_array extension. Building gdal with --no-build-isolation-package lets it see that numpy, fixing "ImportError: cannot import name '_gdal_array' from 'osgeo'" at runtime. * ci: declare setuptools as an extra build dependency for gdal Building gdal with --no-build-isolation-package (previous commit) means it no longer gets setuptools for free from an isolated build env, so its legacy setup.py fails with ModuleNotFoundError: No module named 'setuptools'. uv's own error message pointed at this fix. * ci: install setuptools directly instead of via extra-build-dependencies uv pip install did not pick up [tool.uv.extra-build-dependencies] (same "No module named 'setuptools'" error, with the same hint, reappeared on the next run) - that config apparently only applies to uv's project-aware resolver (uv sync/lock), not the pip-compatible uv pip install used here. Installing setuptools into the venv directly before the --no-build-isolation gdal build is the other fix uv's error suggested, and doesn't depend on that. * fix: scope nested pytest.main() call to its own file in test_timeout_handling Without an explicit path, the nested pytest.main() fell back to the root pyproject.toml's testpaths = ["tests"], which collects the top-level tests/ package instead of this file. That package shares its "tests" module name with packages/map2loop/tests/ (both have __init__.py), so once "tests" was already bound in sys.modules to the map2loop package, the root tests/conftest.py's pytest_plugins entries like "tests.fixtures.data" failed to import - they resolved against the wrong "tests" package. Passing __file__ scopes collection to just this file, avoiding the root tests/ directory entirely.
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