Skip to content

Re-export open_geotiff and to_geotiff from the top-level xrspatial namespace#3006

Merged
brendancol merged 1 commit into
mainfrom
issue-3005
Jun 7, 2026
Merged

Re-export open_geotiff and to_geotiff from the top-level xrspatial namespace#3006
brendancol merged 1 commit into
mainfrom
issue-3005

Conversation

@brendancol

Copy link
Copy Markdown
Contributor

Closes #3005

open_geotiff and to_geotiff were the only public functions you had to import from the subpackage. Now they re-export from the top level like everything else:

  • Add both to xrspatial/__init__.py next to the other top-level re-exports.
  • from xrspatial.geotiff import open_geotiff, to_geotiff still works (same objects).
  • Note the alias in the GeoTIFF reference docs.

No functional change to the readers/writers, so backend coverage (numpy / cupy / dask+numpy / dask+cupy) is untouched.

Test plan

  • test_top_level_reexports_are_the_subpackage_functions pins both spellings to the same objects.
  • Existing test_api_consolidation.py suite still passes (14 passed).

Add the two public GeoTIFF entry points to xrspatial/__init__.py so they
import the same way as every other public function:

    from xrspatial import open_geotiff, to_geotiff

The existing xrspatial.geotiff.* spelling keeps working. Adds a contract
test pinning both spellings to the same objects and notes the alias in
the GeoTIFF reference docs.
@github-actions github-actions Bot added the performance PR touches performance-sensitive code label Jun 7, 2026

@brendancol brendancol left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

PR Review: Re-export open_geotiff and to_geotiff from the top-level xrspatial namespace

Blockers (must fix before merge)

None.

Suggestions (should fix, not blocking)

None.

Nits (optional improvements)

  • The two new imports sit between the zonal and reproject blocks in xrspatial/__init__.py:144-145. The file isn't strictly module-sorted anyway (hydro is scattered too), so this is fine as is. A geotiff block grouped with the other I/O imports would read a touch better, but not enough to warrant a re-push.

What looks good

  • Both spellings resolve to the same objects; xrspatial.open_geotiff is xrspatial.geotiff.open_geotiff holds.
  • There's no top-level __all__ to keep in sync, so the re-export matches how every other public function is exposed.
  • The contract test pins identity, not just importability, so it catches a future accidental shadow.
  • No circular import: the geotiff subpackage doesn't reach back into the top-level package.
  • Backward compatible. The subpackage import keeps working.
  • Docs mention the alias in both the Reading and Writing sections.

Checklist

  • Algorithm matches reference/paper: n/a (no algorithm change)
  • All implemented backends produce consistent results: n/a (no backend change)
  • NaN handling is correct: n/a
  • Edge cases covered by tests: the identity test covers the contract
  • Dask chunk boundaries handled correctly: n/a
  • No premature materialization or unnecessary copies: n/a
  • Benchmark exists or not needed: not needed
  • README feature matrix updated: not applicable (no new function)
  • Docstrings present and accurate: docs updated

@brendancol brendancol merged commit e0217ea into main Jun 7, 2026
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance PR touches performance-sensitive code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Re-export open_geotiff and to_geotiff from the top-level xrspatial namespace

1 participant