-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Missing documentation targets after refactor that moved classes out of core module #10195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I also noticed this with |
Another thing I just noticed, many docstrings are pointing to the old modules. For example: xarray/xarray/core/dataarray.py Line 7075 in 52cafdb
|
we were thinking of putting these in an there's a benefit to having a cleaner top-level namespace, so unless there's no way around that, I'd vote to exclude them we should clean up the docstrings; I'm surprised the docs don't fail. would def take a PR, but if not I'll try and fix soon |
Assuming users are not supposed to directly instantiate those classes, yes I think If there's no rush, I'm happy to fix the docstrings in the next few days. |
thanks a lot @malmans2 ! |
the docs don't fail because the outdated import paths result in broken links, and we'd need to enable nitpicky mode to get errors for that. As far as I can tell, we inherit too many docstrings from |
ah thanks. and we can't do this for our docstrings only? |
At least I couldn't figure out how to do that back when I looked into this (which was a couple of years ago, so something might have changed). However, the point is that we do want to document e.g. |
that makes sense, thanks @keewis |
Hi all, I realised there's a similar issue covering this topic: #10179 I'll open a PR to close this issue later. In the meantime, I've compiled the docs with these variables: nitpicky = True
nitpick_ignore_regex = [
# Ignore all roles that are not py:class
(r"py:(?!class).*", r".*"),
# Ignore all py:class references that do NOT contain "core."
(r"py:class", r"^(?!.*core\.).*"),
] Which I think does the job and returns the list of classes I should fix in the PR:
|
Is your feature request related to a problem?
I've been using
DataArrayWeighted
andDatasetWeighted
for typing purposes. A recent refactor moved these objects fromxarray.core.weighted
toxarray.computation.weighted
, which broke my downstream code. Technically, I guess this is not a breaking change, but those classes are exposed in the documentation (e.g., DataArrayWeighted)Would it be possible to import these objects at the top level in
__init__.py
? If not, what would you recommend for downstream packages? Should they just avoid relying on these classes?Describe the solution you'd like
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: