There was a problem hiding this comment.
A few general notes:
For various reasons, we use tests only sparingly in typeshed for complicated situations. For example, assert_type(reader.bounds, BoundingBox) basically only repeats the type hint and tests that the type checkers works correctly.
Without looking at the tests in detail, we should probably just remove them wholesale for now.
Using Any needs an explanation, which types are allowed or why Any is necessary, unless it's obvious for someone not familar with the library. dict[str, Any] is probably the most common case that's considered obvious, specializations like NDArray[Any] is another case. Example where it's not obvious:
What happens with args and kwargs here? Why can't it be typed? Are they just forwarded? In that case we could type them with the arguments of the function they are forwarded to. Or are they forwarded to a function where the arguments are unknown? Then that should be a comment. Just leaving it unannotated for now is also an option.
Another example:
What's the meaning of Any here?
Sorry, something went wrong.
| rasterio\._typing | ||
| rasterio\._affine_types | ||
| rasterio\.features\.Geometry | ||
| rasterio\.merge\.MethodFunction | ||
|
|
||
| rasterio\._base.* | ||
| rasterio\._io.* | ||
| rasterio\._env.* | ||
| rasterio\._err.* | ||
| rasterio\._features.* | ||
| rasterio\._transform.* |
There was a problem hiding this comment.
There should be comments explaining why these entries are on the allowlist.
Sorry, something went wrong.
There was a problem hiding this comment.
I added comments
Sorry, something went wrong.
| partial-stub = true | ||
|
|
||
| [tool.stubtest] | ||
| ignore-missing-stub = true |
There was a problem hiding this comment.
Are these two options really necessary? Are really modules (that are not listed in the allowlist) missing?
Sorry, something went wrong.
There was a problem hiding this comment.
i removed those flags added missing stubs
Sorry, something went wrong.
|
Thanks for the review. This is ready for another look. I addressed your comments in separate commits. |
Sorry, something went wrong.
|
@srittau please let me know if there are any other changes I should do. Thanks |
Sorry, something went wrong.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Sorry, something went wrong.
Summary
Adds type stubs for rasterio tracking the current rasterio==1.5.* release.
Follow-up to #15870 — please refer to that issue for the discussion that shaped the PR's scope (in particular the decision to ship affine references through a stubs-only indirection instead of bundling types-affine).
Also addresses rasterio/rasterio#2322 (the upstream type-hinting tracker): rasterio's maintainers opted not to add inline annotations, so external stubs are the practical alternative — this PR provides them.
What's included
affine.Affine strategy
Per the discussion on #15870, rasterio's stubs reference affine.Affine through a single stubs-only indirection module (rasterio._affine_types) that aliases Affine to Any:
Affine v3 is currently in the 3.0rc3 pre-release and already ships complete inline type hints plus a py.typed marker (affine.py was moved to affine/__init__.py in rc3 specifically to enable that distribution). When v3 is final, the swap is one line in one file:
This avoids any need to ship types-affine in typeshed.
PEP 702 @deprecated markers
Cover every documented RasterioDeprecationWarning site, including the overload-based parameter deprecations:
…and whole-symbol cases: CRS.is_valid, Window.round_shape, DatasetReaderBase.statistics, DatasetBase.is_tiled, env.hascreds, env.ensure_env_credentialled, io.FilePath, path.parse_path, path.vsi_path.
Two deprecations cannot be expressed via overload because **rpc_options swallows the deprecated kwarg in the modern overload (transform.rowcol(precision=) and transform.TransformMethodsMixin.index(precision=)); these carry inline notes in the stub.
Local validation
Run against rasterio==1.5.0 in a fresh venv:
Notes