• [x] towards #8844

This "fixes" the upstream-dev failures related to the removal of numpy.array_api. There are a couple of open questions, though: - array-api-strict is not installed by default, so namedarray would get a new dependency. Not sure how to deal with that – as far as I can tell, numpy.array_api was not supposed to be used that way, so maybe we need to use array-api-compat instead? What do you think, @andersy005, @Illviljan? - array-api-strict does not define Array.nbytes (causing a funny exception that wrongly claims DataArray does not define nbytes) - array-api-strict has a different DType class, which makes it tricky to work with both numpy dtypes and said dtype class in the same code. In particular, if I understand correctly we're supposed to check dtypes using isdtype, but numpy.isdtype will only exist in numpy>=2, array-api-strict's version does not define datetime / string / object dtypes, and numpy.issubdtype does not work with the non-numpy dtype class). So maybe we need to use array-api-compat internally?

This removes the use of the deprecated numpy.core._exceptions.UFuncError (and multiplication as a way to attach units), and makes sure we run the pint tests in the upstream-dev CI again.

• [x] towards #8844

In the tests, we've been calling np.cross with vectors of 2 or 3 dimensions, numpy>=2 will deprecate 2D vectors (plus, we're now raising on warnings). Thus, we 0-pad the inputs before generating the expected result (which generally should not change the outcome of the tests).

For a later PR: add tests to check if xr.cross works if more than a single dimension is present, and pre-compute the expected result. Also, for property-based testing: the cross-product of two vectors is perpendicular to both input vectors (use the dot product to check that), and its length (l2-norm) is the product of the lengths of the input vectors.

- [x] towards #8844

• replace numpy.core.finfo with numpy.finfo
• add dtype and copy parameters to all definitions of __array__

In trying to install packages that are compatible with numpy>=2 I added several projects that are built in CI without build isolation (so that they will be built with the nightly version of numpy). That was a temporary workaround, so we should start thinking about cleaning this up.

As it seems numcodecs is now compatible (or uses less of numpy in compiled code, not sure), this is an attempt to see if CI works if we use the version from conda-forge.

bottleneck and cftime now build against numpy>=2.0.0rc1, so we can stop building them without build isolation.

Turns out pydap also needs to build with numpy>=2. Until it does, we should remove it from the upstream-dev environment. Also, numcodecs build-depends on setuptools-scm.

And finally, the h5py nightlies might support numpy>=2 (h5py>=3.11 supposedly is numpy>=2 compatible), so once again I'll try and see if CI passes.

• [x] towards #8844

After adding the py38-all-but-dask CI in #3919, it discovered a few backend issues: - zarr: - [x] open_zarr with chunks="auto" always tries to chunk, even if dask is not available (fixed in #3919) - [x] ZarrArrayWrapper.__getitem__ incorrectly passes the indexer's tuple attribute to _arrayize_vectorized_indexer (this only happens if dask is not available) (fixed in #3919) - [x] slice indexers with negative steps get transformed incorrectly if dask is not available https://github.com/pydata/xarray/pull/8674 - rasterio: - ~calling pickle.dumps on a Dataset object returned by open_rasterio fails because a non-serializable lock was used (if dask is installed, a serializable lock is used instead)~

When opening files from path-like objects (str, pathlib.Path), the backend machinery (_dataset_from_backend_dataset) sets the "source" encoding. This is useful if we need the original path for additional processing, like writing to a similarly named file, or to extract additional metadata. This would be useful as well when using fsspec to open remote files.

In this PR, I'm extracting the path attribute that most fsspec objects have to set that value. I've considered using isinstance checks instead of the getattr-with-default, but the list of potential classes is too big to be practical (at least 4 classes just within fsspec itself).

If this sounds like a good idea, I'll update the documentation of the "source" encoding to mention this feature.

• [x] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

FYI @aulemahal, numpy.NaN will be removed in the upcoming numpy=2.0 release.

• [x] follow-up to #8603

According to our policy (and NEP-29) we can drop support for python=3.9 since about a week ago. Interestingly, SPEC0 says we could have started doing this about half a year ago (Q4 2023).

We could delay this until we have a release that is compatible with numpy>=2.0, though (numpy>=2.1 will drop support for python=3.9).

• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

• [x] follow-up to #8846

pandas recently removed the deprecated unit kwarg to TimedeltaIndex.

• [x] towards #8844

There's a couple of accumulated failures now, including a crash because pandas apparently depends on pyarrow now, which on conda-forge is not built for numpy>=2.0.

• [x] closes #8748

After changing the behavior of the implementation of *_like in pint, it seems comparisons fail now. As it turns out, this is because we're using zeros_like to return all-False arrays from isnull for input with non-nullable dtypes.

I'd argue that python full_like(data, dtype=bool, fill_value=False) is a little bit easier to understand than python zeros_like(data, dtype=bool) as the latter requires knowledge about the bit representation of False, so the change is not only to get pint to work properly.

• [x] Tests added

Another one of the numpy=2.0 fixes, this time numpy.core.multiarray.normalize_axis_index has been moved to numpy.lib.array_utils (and apparently this is the first time it has been officially exposed as public API).

Since as far as I remember numpy is working on removing numpy.core entirely, we might also want to change our usage of defchararray (in the formatting tests). Not sure how, though.

• [x] Towards #8091

• [x] Closes #8580

Is your feature request related to a problem?

I frequently find myself computing a handful of variables of a dataset (typically coordinates) and assigning them back to the dataset, and wishing we had a method / function that allowed that.

Describe the solution you'd like

I'd imagine something like python ds.compute(variables=variable_names) but I'm undecided on whether that's a good idea (it might make .compute more complex?)

Describe alternatives you've considered

So far I've been using something like python ds.assign_coords({k: lambda ds: ds[k].compute() for k in variable_names}) ds.pipe(lambda ds: ds.merge(ds[variable_names].compute())) but both are not easy to type / understand (though having .merge take a callable would make this much easier). Also, the first option computes variables separately, which may not be ideal?

Additional context

No response

(namely, additional CI and upstream-dev CI)

python=3.11 has been released more than a year ago and python=3.12 is out as well, which means that it is a good idea to migrate sooner than later.

Regarding python=3.12, usually it is numba that keeps us from testing on a new python version for some time, where numbagg and sparse are the only dependencies that would use it. Should we create a environment without those two dependencies and switch back to the normal one once numba supports the new python version?

We still have the special environment files for python>=3.11 because the normal ones still include cdms2. We deprecated that back in May – not sure which release that ended up in – but since cdms2 will be abandoned end of this year, that's when we're free to drop support and merge both environments (though maybe we can justify dropping support earlier?)

Not sure if this is something that we'll only see on main after the next release of pandas (if ever), though.

I also moved the hdf5 warning to xarray/tests/__init__.py, as that is usually the source of these warnings.

• [x] towards #8091

numpy recently added __array_namespace__ to the ndarray class, which returns the main numpy module. However, that does not yet provide a couple of functions, in this case we need concat. This adds a additional condition to duck_array_ops.concat that disables using __array_namespace__ for ndarray objects.

I tried to run where with chunked cupy arrays: python In [1]: import xarray as xr ...: import cupy ...: import dask.array as da ...: ...: arr = xr.DataArray(cupy.arange(4), dims="x") ...: mask = xr.DataArray(cupy.array([False, True, True, False]), dims="x") this works: python In [2]: arr.where(mask) Out[2]: <xarray.DataArray (x: 4)> array([nan, 1., 2., nan]) Dimensions without coordinates: x this fails: ```python In [4]: arr.chunk().where(mask).compute()

TypeError Traceback (most recent call last) Cell In[4], line 1 ----> 1 arr.chunk().where(mask).compute()

File ~/repos/xarray/xarray/core/dataarray.py:1095, in DataArray.compute(self, kwargs) 1076 """Manually trigger loading of this array's data from disk or a 1077 remote source into memory and return a new array. The original is 1078 left unaltered. (...) 1092 dask.compute 1093 """ 1094 new = self.copy(deep=False) -> 1095 return new.load(kwargs)

File ~/repos/xarray/xarray/core/dataarray.py:1069, in DataArray.load(self, kwargs) 1051 def load(self: T_DataArray, kwargs) -> T_DataArray: 1052 """Manually trigger loading of this array's data from disk or a 1053 remote source into memory and return this array. 1054 (...) 1067 dask.compute 1068 """ -> 1069 ds = self._to_temp_dataset().load(**kwargs) 1070 new = self._from_temp_dataset(ds) 1071 self._variable = new._variable

File ~/repos/xarray/xarray/core/dataset.py:752, in Dataset.load(self, kwargs) 749 import dask.array as da 751 # evaluate all the dask arrays simultaneously --> 752 evaluated_data = da.compute(*lazy_data.values(), kwargs) 754 for k, data in zip(lazy_data, evaluated_data): 755 self.variables[k].data = data

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/base.py:600, in compute(traverse, optimize_graph, scheduler, get, args, kwargs) 597 keys.append(x.dask_keys()) 598 postcomputes.append(x.dask_postcompute()) --> 600 results = schedule(dsk, keys, kwargs) 601 return repack([f(r, a) for r, (f, a) in zip(results, postcomputes)])

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/threaded.py:89, in get(dsk, keys, cache, num_workers, pool, kwargs) 86 elif isinstance(pool, multiprocessing.pool.Pool): 87 pool = MultiprocessingPoolExecutor(pool) ---> 89 results = get_async( 90 pool.submit, 91 pool._max_workers, 92 dsk, 93 keys, 94 cache=cache, 95 get_id=_thread_get_id, 96 pack_exception=pack_exception, 97 kwargs, 98 ) 100 # Cleanup pools associated to dead threads 101 with pools_lock:

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/local.py:511, in get_async(submit, num_workers, dsk, result, cache, get_id, rerun_exceptions_locally, pack_exception, raise_exception, callbacks, dumps, loads, chunksize, **kwargs) 509 _execute_task(task, data) # Re-execute locally 510 else: --> 511 raise_exception(exc, tb) 512 res, worker_id = loads(res_info) 513 state["cache"][key] = res

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/local.py:319, in reraise(exc, tb) 317 if exc.traceback is not tb: 318 raise exc.with_traceback(tb) --> 319 raise exc

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/local.py:224, in execute_task(key, task_info, dumps, loads, get_id, pack_exception) 222 try: 223 task, data = loads(task_info) --> 224 result = _execute_task(task, data) 225 id = get_id() 226 result = dumps((result, id))

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/core.py:119, in _execute_task(arg, cache, dsk) 115 func, args = arg[0], arg[1:] 116 # Note: Don't assign the subtask results to a variable. numpy detects 117 # temporaries by their reference count and can execute certain 118 # operations in-place. --> 119 return func(*(_execute_task(a, cache) for a in args)) 120 elif not ishashable(arg): 121 return arg

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/optimization.py:990, in SubgraphCallable.call(self, *args) 988 if not len(args) == len(self.inkeys): 989 raise ValueError("Expected %d args, got %d" % (len(self.inkeys), len(args))) --> 990 return core.get(self.dsk, self.outkey, dict(zip(self.inkeys, args)))

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/core.py:149, in get(dsk, out, cache) 147 for key in toposort(dsk): 148 task = dsk[key] --> 149 result = _execute_task(task, cache) 150 cache[key] = result 151 result = _execute_task(out, cache)

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/dask/core.py:119, in _execute_task(arg, cache, dsk) 115 func, args = arg[0], arg[1:] 116 # Note: Don't assign the subtask results to a variable. numpy detects 117 # temporaries by their reference count and can execute certain 118 # operations in-place. --> 119 return func(*(_execute_task(a, cache) for a in args)) 120 elif not ishashable(arg): 121 return arg

File <array_function internals>:180, in where(args, *kwargs)

File cupy/_core/core.pyx:1723, in cupy._core.core._ndarray_base.array_function()

File ~/.local/opt/mambaforge/envs/xarray/lib/python3.10/site-packages/cupy/_sorting/search.py:211, in where(condition, x, y) 209 if fusion._is_fusing(): 210 return fusion._call_ufunc(_where_ufunc, condition, x, y) --> 211 return _where_ufunc(condition.astype('?'), x, y)

File cupy/_core/_kernel.pyx:1287, in cupy._core._kernel.ufunc.call()

File cupy/_core/_kernel.pyx:160, in cupy._core._kernel._preprocess_args()

File cupy/_core/_kernel.pyx:146, in cupy._core._kernel._preprocess_arg()

TypeError: Unsupported type <class 'numpy.ndarray'> this works again:python In [7]: arr.chunk().where(mask.chunk(), cupy.array(cupy.nan)).compute() Out[7]: <xarray.DataArray (x: 4)> array([nan, 1., 2., nan]) Dimensions without coordinates: x `` And other methods likefillna` show similar behavior.

I think the reason is that this: https://github.com/pydata/xarray/blob/d4db16699f30ad1dc3e6861601247abf4ac96567/xarray/core/duck_array_ops.py#L195 is not sufficient to detect cupy beneath other layers of duckarrays (most commonly dask, pint, or both). In this specific case we could extend the condition to also match chunked cupy arrays (like arr.cupy.is_cupy does, but using is_duck_dask_array), but this will still break for other duckarray layers or if dask is not involved, and we're also in the process of moving away from special-casing dask. So short of asking cupy to treat 0d arrays like scalars I'm not sure how to fix this.

cc @jacobtomlinson

cdms2 is going to be abandoned at the end of this year, the recommended replacement is xcdat. We have deprecated our conversion functions in 2023.06.0 (release on June 23) which was less than 6 months ago, but given that cdms2 is already not installable on some architectures it makes sense to remove earlier.

This also appears to allow us to remove the special python=3.11 environment files.

• [x] Follow-up to #7876, closes #8419
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

The upstream-dev CI currently fails sometimes due to a segfault (the normal CI crashes, too, but since we use pytest-xdist we only get a message stating "worker x crashed").

I'm not sure why, and I can't reproduce locally, either. Given that dask's local scheduler is in the traceback and the failing test is test_open_mfdataset_manyfiles, I assume there's some issue with parallel disk access or the temporary file creation.

What is your issue?

We frequently get bug reports related to encoding that can usually be fixed by clearing it or by overriding it using the encoding parameter of the to_* methods, e.g. - #4224 - #4380 - #4655 - #5427 - #5490 - fsspec/kerchunk#130

There are also a few discussions with more background: - https://github.com/pydata/xarray/pull/5065#issuecomment-806154872 - https://github.com/pydata/xarray/issues/1614 - #5082 - #5336

We discussed this in the meeting yesterday and as far as I can remember agreed that the current default behavior is not ideal and decided to investigate #5336: a keep_encoding option, similar to keep_attrs, that would be True (propagate encoding) by default but will be changed to False (drop encoding on any operation) in the future.

cc @rabernat, @shoyer

With NEP 51 (and the changes to numpy main), scalar types no longer pretend to be standard python types in their string representation. This fixes most of the errors in the tests but there are still a few remaining in the doctests (in particular, doctests for private plotting utils).

• [x] towards #8091

The docs have been failing because of a malformatted docstring we inherit from pandas, and this caused us to miss another error in #8183. The fix is to avoid installing pandas=2.1.0, which should be the only version with the malformatted docstring, and to apply the missing changes from #8183 here.

• [x] Closes #8157, follow-up to #8183

• [x] towards #8091
• [x] closes #8133

Edit: looking at the relevant numpy issues, it appears numpy will stay a bit unstable for the next few weeks / months. Not sure how quickly we should try to adapt to those changes.

• [x] follow-up to #7415

It seems in a previous PR I "temporarily" pinned numpy to get CI to pass, but then forgot to unpin later and merged it as-is. As a result, we have not been running the main CI with numpy>=1.24 ever since, even though now numpy=1.25 has been around for a while.

Indexes contains one entry per coordinate, even if there are indexes that index multiple coordinates. This deduplicates the entries, but the format is not quite clear.

• [x] follow-up to #6795
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

The formatting options we were able to come up with: 1. separate with just newlines (see e29aeb9085bc677e16dabd4a2b94cf63d06c155e): Indexes: one CustomIndex two three PandasIndex 2. mark unique indexes with a prefix to make it look like a list (see 9b90f8bceda6f012c863927865cc638e0ff3fb88): Indexes: - one CustomIndex two - three PandasIndex 3. use unicode box components (in front of the coordinate names) (see 2cec070ebf4f1958d4ffef98d7649eda21ac09a3): Indexes: ┌ one CustomIndex │ two └ three four PandasIndex 4. use unicode box components (after the coordinate names) (see 492ab47ccce8c43d264d5c759841060d33cafe4d): Indexes: one ┐ CustomIndex two │ three ┘ four PandasIndex

For the unicode box components, we can choose between the light and heavy variants.

@benbovy and I think the unicode variants (especially variant 3) are the easiest to understand, but we would need to decide whether we care about terminals that don't support unicode.

Edit: in the meeting we decided that support for the subsection of unicode should be common enough that we can use it. I'll clean this PR up to implement option 3, then.

RTD is deprecating the feature flag we made use of before.

PyPI introduced the concept of "trusted publishers" a few months ago, which allows requesting short-lived API tokens for trusted publishing services (such as GHA, in our case).

Someone with the appropriate rights will have to enable this on PyPI, and I will do the same for TestPyPI.

Storing a reference to the function on the class tells the garbage collector to not collect the function before the class, such that any instance can safely complete its __del__.

No tests because I don't know how to properly test this. Any ideas?

• [x] Closes #7814
• [ ] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

With the recent addition of the workflow to upload nightly releases to anaconda.org/scientific-python-nightly-wheels, we don't really need the TestPyPI workflow anymore, especially since PyPI instances are not designed to automatically delete very old releases.

• [x] Follow-up to #7863 and #7865
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

numba=0.57.0 has been out for quite some time already and is available on conda-forge as-of last week, which means we can almost retire the separate python=3.11 environment file.

I'm not sure what to do about cdms2 (we will see if that fails in CI), but in any case we should just deprecate and remove any functions that use it: if I understand correctly, cdms2 is in maintenance mode until the end of the year and will be discontinued afterwards.

The provision-with-micromamba action has been deprecated and will not receive any further releases. It is replaced by the setup-micromamba action, which does basically the same thing, but with a different implementation and a few changes to the configuration.

• [x] Closes #7877

As the cdms2 library has been deprecated and will be retired at the end of this year, maintaining conversion functions does not make sense anymore. Additionally, one of the tests is currently failing on the upstream-dev CI (cdms2 is incompatible with a recent change to numpy), and it seems unlikely this will ever be fixed (and there's no python=3.11 release, blocking us from merging the py311 environment with the default one).

cc @tomvothecoder for visibility

• [x] Closes #7707
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

numpy has recently changed the result of np.cos(0) by a very small value, which makes our tests break.

I'm not really sure what the best fix is, so I split the changes into two parts: the first commit uses python xr.testing.assert_allclose(a + 1, np.cos(a)) to test the result, while the second commit uses python expected = xr.full_like(a, fill_value=np.cos(0), dtype=float) actual = np.cos(a) xr.testing.assert_identical(actual, expected)

• [x] towards #7707

• [x] towards #7707

pint recently improved the support for wrapping dask, breaking our older tests. With this change, we basically require the newest version of pint (pint>=0.21.1, which should be released pretty soon) to interact with dask, as 0.21.0 did break our use of np.allclose and np.isclose. However, I guess dask support has never been properly tested and thus should be considered "experimental", anyways.

As discussed in #7765, this extends the policy months by 6 to a total of 30 months. With that, the support for a python version can be removed as soon as the next version is at least 30 months old. Together with the 12 month release cycle python has, we get the 42 month release window from NEP 29.

Note that this is still missing the release overview proposed in #7765, I'm still thinking about how to best implement the automatic update / formatting, and how to coordinate it with the (still manual) version overrides.

• [x] towards #7765, closes #7777
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

The most recent runs of the type checking CI have started to fail with a segfault: /home/runner/work/_temp/dac0c060-b19a-435a-8063-bbc5b8ffbf24.sh: line 1: 2945 Segmentation fault (core dumped) python -m mypy --install-types --non-interactive --cobertura-xml-report mypy_report This seems to be due to the release of mypy=0.990.

7269 pinned mypy to mypy<0.990, which should be undone once we figured out how to fix that (most likely by waiting on the next release), and any complaints the new version has (see this workflow run).

Apparently, in addition to formatting notebooks, black-jupyter does exactly the same thing as black.

As a follow-up to #7724, this makes the what's new entry a bit more precise.

As mentioned in https://github.com/pydata/xarray/issues/7716#issuecomment-1497623839, this tries to unpin pandas.

From #4355

@max-sixty:

Stepping back on the contributing doc — I admit I haven't look at it in a while — I wonder whether we can slim it down a bit, for example by linking to other docs for generic tooling — I imagine we're unlikely to have the best docs on working with GH, for example. Or referencing our PR template rather than the (now out-of-date) PR checklist.

We could also add a docstring guide since the numpydoc guide does not cover every little detail (for example, default notation, type spec vs. type hint, space before the colon separating parameter names from types, no colon for parameters without types, etc.)

Apparently, read_binary has been marked as deprecated in python=3.11, and is to be replaced by importlib.resources.files, which has been available since python=3.9. Since we dropped support for python=3.8 a while ago, we can safely follow the instructions in the deprecation warning.

The macos 3.11 CI seems stall very often at the moment, which makes it hit the 6 hours mark and get cancelled. Since our tests should never run that long (the ubuntu runners usually take between 15-20 minutes), I'm introducing a pretty generous timeout of 5 minutes. By comparison, we already have a timeout of 60 seconds in the upstream-dev CI, but that's on a ubuntu runner which usually is much faster than any of the macos / windows runners.

Tests that time out raise an error, which might help us with figuring out which test it is that stalls, and also if we can do anything about that.

This is a (incomplete) checklist for #5816 to make it easier to find methods that are in need of examples and links to the narrative docs with further information (of course, changes to the docstrings of all other methods / functions part of the public API are also appreciated).

Good examples explicitly construct small xarray objects to make it easier to follow (e.g. use np.{ones,full,zeros} or the np.array constructor instead of np.random / loading from files) and show both input and output of the function.

Use sh pytest --doctest-modules xarray --ignore xarray/tests/ to verify the examples, or push to a PR to have the CI do it for you (note that you will have much quicker feedback locally though).

To easily generate the expected output install pytest-accept (docs) in your dev environment and then run pytest --doctest-modules FILE_NAME --accept || true

To link to other documentation pages we can use python :doc:`project:label` Description of the linked page where we can leave out project if we link to somewhere within xarray's documentation. To figure out the label, we can either look at the source, search the output of python -m sphinx.ext.intersphinx https://docs.xarray.dev/en/latest/objects.inv, or use sphobjinv (install from PyPI): sh sphobjinv search -su https://docs.xarray.dev/en/latest/ missing

Top-level functions: - [ ] get_options - [ ] decode_cf - [ ] polyval - [ ] unify_chunks - [ ] infer_freq - [ ] date_range

I/O: - [ ] load_dataarray - [ ] load_dataset - [ ] open_dataarray - [ ] open_dataset - [ ] open_mfdataset

Contents: - [ ] DataArray.assign_attrs, Dataset.assign_attrs - [ ] DataArray.expand_dims, Dataset.expand_dims - [ ] DataArray.drop_duplicates, Dataset.drop_duplicates - [ ] DataArray.drop_vars, Dataset.drop_vars - [ ] Dataset.drop_dims - [ ] DataArray.convert_calendar, Dataset.convert_calendar - [ ] DataArray.set_coords, Dataset.set_coords - [ ] DataArray.reset_coords, Dataset.reset_coords

Comparisons: - [ ] DataArray.equals, Dataset.equals - [ ] DataArray.identical, Dataset.identical - [ ] DataArray.broadcast_equals, Dataset.broadcast_equals

Dask: - [ ] DataArray.compute, Dataset.compute - [ ] DataArray.chunk, Dataset.chunk - [ ] DataArray.persist, Dataset.persist

Missing values: - [ ] DataArray.bfill, Dataset.bfill - [ ] DataArray.ffill, Dataset.ffill - [ ] DataArray.fillna, Dataset.fillna - [ ] DataArray.dropna, Dataset.dropna

Indexing: - [ ] DataArray.loc (no docstring at all - came up in https://github.com/pydata/xarray/discussions/7528#discussion-4858556) - [ ] DataArray.drop_isel - [ ] DataArray.drop_sel - [ ] DataArray.head, Dataset.head - [ ] DataArray.tail, Dataset.tail - [ ] DataArray.interp_like, Dataset.interp_like - [ ] DataArray.reindex_like, Dataset.reindex_like - [ ] Dataset.isel

Aggregations: - [ ] Dataset.argmax - [ ] Dataset.argmin - [ ] DataArray.cumsum, Dataset.cumsum (intermediate to advanced) - [ ] DataArray.cumprod, Dataset.cumprod (intermediate to advanced) - [ ] DataArray.reduce, Dataset.reduce

In one of the recent setuptools releases pkg_resources finally got deprecated in favor of the importlib.* modules. We don't use pkg_resources directly, so the DeprecationWarning that causes the doctest CI to fail is from a dependency. As such, the only way to get it to work again is to ignore the warning until the upstream packages have released versions that don't use/import pkg_resources.

Most notably: - bump python to 3.10 - bump sphinx to at least 5.0 - remove the pydata-sphinx-theme pin: sphinx-book-theme pins to a exact minor version so pinning as well does not change anything - xref https://github.com/executablebooks/sphinx-book-theme/issues/686

~Edit: it seems this is blocked by sphinx-book-theme pinning sphinx to >=3,<5. They already changed the pin, we're just waiting on a release~

Since the last time the RTD configuration was updated, a few things have changed: - the OS image is now a bit old - we can tell git (and thus setuptools_scm) to ignore changes by RTD

If I read the documentation / history of RTD correctly, they removed the DONT_SHALLOW_CLONE feature flag from documentation (it still is enabled and works for this repository, though), so we might have to migrate to adding a post_checkout build job that does that soon.

We can't use the example grep options because we usually enclose tags with [], which grep will interpret as character classes.

RTD somewhat recently introduced the build.jobs setting, which allows skipping builds (technically it's more of a "automated cancel" with a special error code instead of a skip) on user-defined conditions. We can use that to manually "skip" builds we don't need a documentation build for.

Edit: the only downside seems to be that the build is not actually marked as "skipped" Edit2: apparently that's a bug that's being worked on, see readthedocs/readthedocs.org#9807

This builds on #7353, which found that cdms2 and numba (and thus also numbagg and sparse) don't yet support python=3.11.

In order to still test that we support python=3.11 but without dropping those dependencies from the other environments, this adds separate environment files, which should be removed once cdms2 and numba support python=3.11.

It seems there is a numbagg package on conda-forge now.

Not sure what to do about the min-all-deps CI, but given that the most recent version of numbagg happened more than 12 months ago (more than 18 months, even) maybe we can just bump it to the version on conda-forge?

• [x] opposite of #7311
• [x] closes #7306

Using the numpy HEAD together with numba is, in general, not supported (see numba/numba#8615). So in order to avoid the current failures and still be able to test numpy HEAD, this (temporarily) removes numbagg and numba (pulled in through numbagg), from the upstream-dev CI.

We currently have two upstream-dev PR CI: the old pipelines CI and the new github actions CI added together with the scheduled upstream-dev ("nightly") CI. Since we don't need both I think we should disable one of these, presumably the old pipelines CI.

There's an issue with the CI result, though: since github doesn't have a icon for "passed with issues", we have to choose between "passed" or "failed" as the CI result (neither of which is optimal).

The advantage of using "failed" is that a failure is easily visible, but often the total CI result on PRs is set to "failed" because we didn't get around to fixing bugs introduced by recent changes to dependencies (which is confusing for contributors).

In #4584 I switched the pipelines upstream-dev CI to "allowed failure" so we get a warning instead of a failure. However, github doesn't print the number of warnings in the summary line, which means that if the icon is green nobody checks the status and upstream-dev CI failures are easily missed.

Our new scheduled nightly CI improves the situation quite a bit since we automatically get a issue containing the failures, but that means we aren't able to catch these failures before actually merging. As pointed out in https://github.com/pydata/xarray/issues/4574#issuecomment-725795622 that might be acceptable, though.

If we still want to fix this, we could have the PR CI automatically add a comment to the PR, which would contain a summary of the failures but also state that these failures can be ignored as long as they get the approval of a maintainer. This would increase the noise on PRs, though.

I ran into this while trying DataTree.pad, which silently dropped the attrs, even with keep_attrs=True.

• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

The type checking CI has started to fail with the new upgrade. In order not to disturb unrelated PRs, this pins mypy to a known good version (mypy<0.990).

Like most github actions (or at least all the official actions/* ones), issue-from-pytest-log maintains a moving release tag that points to the most recently released version.

In order to decrease the amount of updating PRs, this makes use of that tag.

While working on #7241, I realized that I forgot to specify the python in our main CI, with the effect that we've been testing python 3.10 twice for each OS since the introduction of the micromamba action.

I'm not sure if we actually need the dedicated "report" job, or whether adding an additional step to the main ci job would suffice?

I can see two reasons for a separate job: 1. we get to control the python version independently from the version of the main job 2. we upload the reportlog files as artifacts

I think if we can change the action to abort if it is run on a python version it does not support the first concern would not matter anymore, and for 2 we might just keep the "upload artifact" action (but is it even possible to manually access artifacts? If not we might not even need the upload).

Since I don't think either is a major concern, I went ahead and joined the jobs.

• [x] Closes #6810

In order to follow the minor releases of ci-trigger, we can use the new v1 release tag that will always point to the most recent release.

To see the effect, try this:

~The repr looks a bit strange because I've been borrowing the variable CSS classes.~ Edit: @benbovy fixed that for me

Also, the discussion about what _repr_inline_ should include from #7183 is relevant here as well.

• [x] Follow-up to #6795, depends on #7183
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Also, some tests for the index summarizer.

• [x] Follow-up to #6795
• [x] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

With the flexible indexes refactor indexes have become much more important, which means we should include them in the reprs of DataArray and Dataset objects.

This is a initial attempt, covering only the string reprs, with a few unanswered questions: - how do we format indexes? Do we delegate to their __repr__ or some other method? - should we skip PandasIndex and PandasMultiIndex? - how do we present indexes that wrap multiple columns? At the moment, they are duplicated (see also the discussion in #6392) - what do we do with the index marker in the coords repr?

(also, how do we best test this?)

• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

We started to pin the version of black used in the environment of blackdoc, but the version becomes out-of-date pretty quickly. The new hook I'm adding here is still experimental, but pretty limited in what it can destroy (the pre-commit configuration) so for now we can just review any new autoupdate PRs from the pre-commit-ci a bit more thoroughly.

This is the first of a series of PRs to add a framework to make testing the integration of duck arrays as simple as possible. It uses hypothesis for increased coverage and maintainability.

• [x] Tests added
• [x] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

At the moment, nanprod and nansum will replace any nan values with 1 for nanprod or 0 for nansum. For pint, inserting dimensionless values into quantities is explicitly not allowed, so our version of nanprod cannot be used on pint quantities (0 is a exception so nansum does work).

I'm proposing to rely on numpy's version for that, which would allow pint to customize the behavior.

We could probably replace the default indexes with cudf indexes, but with pandas indexes this test doesn't make too much sense.

pint's implementation of NEP-18 (see hgrecco/pint#905) is close enough so we can finally start working on the pint support (i.e. make the integration tests pass). This would be the list of tasks to get there: * integration tests: - [x] implement integration tests for DataArray, Dataset and top-level functions (#3238, #3447, #3493) - [x] add tests for Variable as discussed in #3493 (#3654) - [x] clean up the current tests (#3600) - [x] use the standard assert_identical and assert_allclose functions (#3611, #3643, #3654, #3706, #3975) - [x] clean up the TestVariable.test_pad tests * actually get xarray to support units: - [x] top-level functions (#3611) - [x] Variable (#3706) + rolling_window and identical need larger modifications - [x] DataArray (#3643) - [x] Dataset - [x] silence all the UnitStrippedWarnings in the testsuite (#4163) - [ ] try to get nanprod to work with quantities - [x] add support for per variable fill values (#4165) - [x] repr with units (#2773) - [ ] type hierarchy (e.g. for np.maximum(data_array, quantity) vs np.maximum(quantity, data_array)) (#3950) * update the documentation - [x] point to pint-xarray (see #4530) - [x] mention the requirement for UnitRegistry(force_ndarray=True) or UnitRegistry(force_ndarray_like=True) (see https://pint-xarray.readthedocs.io/en/stable/creation.html#attaching-units) - [x] list the known issues (see https://github.com/pydata/xarray/pull/3643#issue-354872657 and https://github.com/pydata/xarray/pull/3643#issuecomment-602225731) (#4530): + pandas (indexing) + bottleneck (bfill, ffill) + scipy (interp) + numbagg (rolling_exp) + numpy.lib.stride_tricks.as_strided: rolling + numpy.vectorize: interpolate_na - [x] ~update the install instructions (we can use standard conda / pip now)~ this should be done by pint-xarray

There's a few unreleased and potentially breaking changes in main, most importantly the index refactor and the new groupby using numpy-groupies and flox. During the meeting on Wednesday we decided to release a preview version to get feedback before releasing a full version, especially from those who don't run their tests against our main branch.

I am planning to create the pre-release tomorrow, but if there's any big changes that should be included please post here.

cc @TomNicholas

Edit: the version will be called 2022.05.0.dev0, which will ensure that e.g. pip will require the --pre flag to install it.

The editable install on RTD is reported to have the version 0.17.1.dev0+g835a53e6.d20210226 (which technically is correct but it would be better to have a clean version on tags).

This is not something I can reproduce with python -m pip install -e ., so it is either some RTD weirdness or happens because we get mamba to do the editable install for us.

We should try to get the version right.

The reason the changes introduced in #6542 caused timeouts is that they redefined ds to a bigger dataset, which would then be used to demonstrate to_dict.

The fix is to explicitly set the dataset before calling to_dict, which also makes that section a bit easier to follow.

• [x] Closes #6720

The most recent runs of the mypy CI on main are failing with: xarray/core/dataset.py:6934: error: Incompatible types in assignment (expression has type "str", variable has type "Optional[Optional[Literal['Y', 'M', 'W', 'D', 'h', 'm', 's', 'ms', 'us', 'ns', 'ps', 'fs', 'as']]]") [assignment] I'm not sure what changed since the last pass, though.

• [x] Closes #6698

We currently use the output of pytest to generate our test results, which is both fragile and does not detect import errors on test collection.

Instead, we can use pytest-reportlog to generate a machine-readable file that is easy to parse (junit XML would probably work, too, but apparently does not contain all the different failure modes of pytest).

The new script will collect failure summaries like the old version, but it should be fairly easy to create a fancy report with more information.

I'm not sure if this is exactly equal to what we had before, but we might be able to save 3-4 minutes of CI time with this.

• [x] supersedes and closes #6544

• [x] follow-up to #4947

This starts adding the parametrized accessor examples from #3829 to the accessor documentation as suggested by @jhamman. Since then the weighted methods have been added, though, so I'd like to use a different example instead (ideas welcome).

Also, this feature can be abused to add functions to the main DataArray / Dataset namespace (by registering a function with the register_*_accessor decorators, see the second example). Is this something we want to explicitly discourage?

(~When trying to build the docs locally, sphinx keeps complaining about a code block without code. Not sure what that is about~ seems the ipython directive does not allow more than one expression, so I used code instead)

• [x] Closes #3829
• [x] Passes isort -rc . && black . && mypy . && flake8
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

as discussed in #4837, this adds a method that applies a function to a DataArray by first converting it to a temporary dataset using _to_temp_dataset, applies the function and converts it back. I'm not really happy with the name but I can't find a better one.

This function is really similar to pipe, so I guess a keyword argument to pipe would work, too. The disadvantage of that is that pipe passes all kwargs to the passed function, which means we would shadow a specific kwarg.

• [x] Closes #4837
• [x] Tests added
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

Follow-up to #4896: this creates the context object in reduce methods and passes it to merge_attrs, with more planned.

• [ ] might help with xarray-contrib/cf-xarray#228
• [ ] Tests added
• [x] Passes pre-commit run --all-files
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

Note that for now this is a bit inconvenient to use for provenance tracking (as discussed in the cf-xarray issue) because functions implementing that would still have to deal with merging the attrs.

The only thing it contains so far is the known regression, do we want to have a summary of the most notable changes like in the previous releases?

• [x] towards #6645

cc @pydata/xarray

What is your issue?

As I mentioned in the meeting today, we have a lot of features where the the exception group support from PEP654 (which is scheduled for python 3.11 and consists of the class and a syntax change) might be useful. For example, we might want to collect all errors raised by rename in a exception group instead of raising them one-by-one.

For python<=3.10 there's a backport that contains the class and a workaround for the new syntax.

Hopefully the final follow-up to #6660.

As per https://github.com/pydata/xarray/issues/6659#issuecomment-1148285401, don't invoke git restore.

• [x] Closes #6659

This works around a incompatibility between setuptools>=60 and setuptools_scm.

• [x] Closes #6659

follow-up to #6660

This adds a new workflow that uploads every commit to main as a new wheel to TestPyPI. No tests, though, so those wheels might be broken (but that's fine, I guess).

Should we document this somewhere, like the install guide?

• [x] Closes #6659
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

When adding two DataArray objects with different coordinates to a Dataset, a MergeError is raised even though one of the conflicting coords is a subset of the other. Merging dimension coordinates works so I'd expect associated non-dimension coordinates to work, too.

This fails: ```python In [1]: import xarray as xr ...: import numpy as np

In [2]: a = np.linspace(0, 1, 10) ...: b = np.linspace(-1, 0, 12) ...: ...: x_a = np.arange(10) ...: x_b = np.arange(12) ...: ...: y_a = x_a * 1000 ...: y_b = x_b * 1000 ...: ...: arr1 = xr.DataArray(data=a, coords={"x": x_a, "y": ("x", y_a)}, dims="x") ...: arr2 = xr.DataArray(data=b, coords={"x": x_b, "y": ("x", y_b)}, dims="x") ...: ...: xr.Dataset({"a": arr1, "b": arr2}) ... MergeError: conflicting values for variable 'y' on objects to be combined. You can skip this check by specifying compat='override'. While this works:python In [3]: a = np.linspace(0, 1, 10) ...: b = np.linspace(-1, 0, 12) ...: ...: x_a = np.arange(10) ...: x_b = np.arange(12) ...: ...: y_a = x_a * 1000 ...: y_b = x_b * 1000 ...: ...: xr.Dataset({ ...: "a": xr.DataArray(data=a, coords={"x": x_a}, dims="x"), ...: "b": xr.DataArray(data=b, coords={"x": x_b}, dims="x"), ...: }) Out[3]: <xarray.Dataset> Dimensions: (x: 12) Coordinates: * x (x) int64 0 1 2 3 4 5 6 7 8 9 10 11 Data variables: a (x) float64 0.0 0.1111 0.2222 0.3333 0.4444 ... 0.8889 1.0 nan nan b (x) float64 -1.0 -0.9091 -0.8182 -0.7273 ... -0.1818 -0.09091 0.0 ```

I can work around this by calling: python In [4]: xr.merge([arr1.rename("a").to_dataset(), arr2.rename("b").to_dataset()]) Out[4]: <xarray.Dataset> Dimensions: (x: 12) Coordinates: * x (x) int64 0 1 2 3 4 5 6 7 8 9 10 11 y (x) float64 0.0 1e+03 2e+03 3e+03 ... 8e+03 9e+03 1e+04 1.1e+04 Data variables: a (x) float64 0.0 0.1111 0.2222 0.3333 0.4444 ... 0.8889 1.0 nan nan b (x) float64 -1.0 -0.9091 -0.8182 -0.7273 ... -0.1818 -0.09091 0.0 but I think the Dataset constructor should be capable of that, too.

The documentation warns that the universal functions in xarray.ufuncs should not be used unless compatibility with numpy < 1.13 is required.

Since we only support numpy >= 1.15: is it time to remove that (already deprecated) module?

Since there are also functions that are not true ufuncs (e.g. np.angle and np.median) and need __array_function__ (or something similar, see #3917), we could also keep those and just remove the ones that are dispatched using __array_ufunc__.

nbconvert released a fixed version today, so we can remove the pin of jinja2.

• [x] Follow-up to #6415

(detected while trying to implement a PintMetaIndex in xarray-contrib/pint-xarray#163)

This fixes position-based indexing of duck dask arrays: ``` python

In [1]: import xarray as xr ...: impIn [1]: import xarray as xr ...: import dask.array as da ...: import pint ...: ...: ureg = pint.UnitRegistry(force_ndarray_like=True) ...: ...: a = da.zeros((20, 20), chunks=(10, 10)) ...: q = ureg.Quantity(a, "m") ...: ...: arr1 = xr.DataArray(a, dims=("x", "y")) ...: arr2 = xr.DataArray(q, dims=("x", "y"))

In [2]: arr1.isel(x=[0, 2, 4], y=[1, 3, 5]) Out[2]: <xarray.DataArray 'zeros_like-d81259c3a77e6dff3e60975e2afe4ff9' (x: 3, y: 3)> dask.array<getitem, shape=(3, 3), dtype=float64, chunksize=(3, 3), chunktype=numpy.ndarray> Dimensions without coordinates: x, y

In [3]: arr2.isel(x=[0, 2, 4], y=[1, 3, 5])

NotImplementedError Traceback (most recent call last) Input In [3], in <module> ----> 1 arr2.isel(x=[0, 2, 4], y=[1, 3, 5])

File .../xarray/core/dataarray.py:1220, in DataArray.isel(self, indexers, drop, missing_dims, **indexers_kwargs) 1215 return self._from_temp_dataset(ds) 1217 # Much faster algorithm for when all indexers are ints, slices, one-dimensional 1218 # lists, or zero or one-dimensional np.ndarray's -> 1220 variable = self._variable.isel(indexers, missing_dims=missing_dims) 1221 indexes, index_variables = isel_indexes(self.xindexes, indexers) 1223 coords = {}

File .../xarray/core/variable.py:1172, in Variable.isel(self, indexers, missing_dims, **indexers_kwargs) 1169 indexers = drop_dims_from_indexers(indexers, self.dims, missing_dims) 1171 key = tuple(indexers.get(dim, slice(None)) for dim in self.dims) -> 1172 return self[key]

File .../xarray/core/variable.py:765, in Variable.getitem(self, key) 752 """Return a new Variable object whose contents are consistent with 753 getting the provided key from the underlying data. 754 (...) 762 array x.values directly. 763 """ 764 dims, indexer, new_order = self._broadcast_indexes(key) --> 765 data = as_indexable(self._data)[indexer] 766 if new_order: 767 data = np.moveaxis(data, range(len(new_order)), new_order)

File .../xarray/core/indexing.py:1269, in NumpyIndexingAdapter.getitem(self, key) 1267 def getitem(self, key): 1268 array, key = self._indexing_array_and_key(key) -> 1269 return array[key]

File .../lib/python3.9/site-packages/pint/quantity.py:1899, in Quantity.getitem(self, key) 1897 def getitem(self, key): 1898 try: -> 1899 return type(self)(self._magnitude[key], self._units) 1900 except PintTypeError: 1901 raise

File .../lib/python3.9/site-packages/dask/array/core.py:1892, in Array.getitem(self, index) 1889 return self 1891 out = "getitem-" + tokenize(self, index2) -> 1892 dsk, chunks = slice_array(out, self.name, self.chunks, index2, self.itemsize) 1894 graph = HighLevelGraph.from_collections(out, dsk, dependencies=[self]) 1896 meta = meta_from_array(self._meta, ndim=len(chunks))

File .../lib/python3.9/site-packages/dask/array/slicing.py:174, in slice_array(out_name, in_name, blockdims, index, itemsize) 171 index += (slice(None, None, None),) * missing 173 # Pass down to next function --> 174 dsk_out, bd_out = slice_with_newaxes(out_name, in_name, blockdims, index, itemsize) 176 bd_out = tuple(map(tuple, bd_out)) 177 return dsk_out, bd_out

File .../lib/python3.9/site-packages/dask/array/slicing.py:196, in slice_with_newaxes(out_name, in_name, blockdims, index, itemsize) 193 where_none[i] -= n 195 # Pass down and do work --> 196 dsk, blockdims2 = slice_wrap_lists(out_name, in_name, blockdims, index2, itemsize) 198 if where_none: 199 expand = expander(where_none)

File .../lib/python3.9/site-packages/dask/array/slicing.py:242, in slice_wrap_lists(out_name, in_name, blockdims, index, itemsize) 238 where_list = [ 239 i for i, ind in enumerate(index) if is_arraylike(ind) and ind.ndim > 0 240 ] 241 if len(where_list) > 1: --> 242 raise NotImplementedError("Don't yet support nd fancy indexing") 243 # Is the single list an empty list? In this case just treat it as a zero 244 # length slice 245 if where_list and not index[where_list[0]].size:

NotImplementedError: Don't yet support nd fancy indexing ```

• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

sphinx is now close to releasing 4.5, but we're still pinning it to sphinx<4.

Along with it, this updates our RTD configuration.

What happened?

reindex stopped propagating attrs (detected in xarray-contrib/pint-xarray#159).

As far as I can tell, the new reindexing code in Aligner does not handle attrs yet?

Minimal Complete Verifiable Example

```Python

before #5692

In [1]: import xarray as xr ...: ...: xr.set_options(keep_attrs=True) ...: ...: ds = xr.tutorial.open_dataset("air_temperature")

In [2]: ds.reindex(lat=range(10, 80, 5)).lat Out[2]: <xarray.DataArray 'lat' (lat: 14)> array([10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75]) Coordinates: * lat (lat) int64 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Attributes: standard_name: latitude long_name: Latitude units: degrees_north axis: Y

In [3]: ds.reindex(lat=xr.DataArray(range(10, 80, 5), attrs={"attr": "value"}, dims="lat")).lat Out[3]: <xarray.DataArray 'lat' (lat: 14)> array([10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75]) Coordinates: * lat (lat) int64 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Attributes: standard_name: latitude long_name: Latitude units: degrees_north axis: Y

after #5692

In [3]: import xarray as xr ...: ...: xr.set_options(keep_attrs=True) ...: ...: ds = xr.tutorial.open_dataset("air_temperature")

In [4]: ds.reindex(lat=range(10, 80, 5)).lat Out[4]: <xarray.DataArray 'lat' (lat: 14)> array([10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75]) Coordinates: * lat (lat) int64 10 15 20 25 30 35 40 45 50 55 60 65 70 75

In [5]: ds.reindex(lat=xr.DataArray(range(10, 80, 5), attrs={"attr": "value"}, dims="lat")).lat Out[5]: <xarray.DataArray 'lat' (lat: 14)> array([10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75]) Coordinates: * lat (lat) int64 10 15 20 25 30 35 40 45 50 55 60 65 70 75 ```

Since the dependency issue has been fixed upstream, this reverts pydata/xarray#6350

This can be reverted once the nbconvert package on conda-forge has been updated.

What happened?

scipy seems to have some trouble with their documentation host setup, which means that trying to fetch its intersphinx registry returns a 404.

There's nothing we can do to really fix this, but we can try to the avoid docs build failures by disabling that intersphinx entry (not sure if that results in other errors, though)

What did you expect to happen?

No response

Minimal Complete Verifiable Example

No response

Relevant log output

python WARNING: failed to reach any of the inventories with the following issues: intersphinx inventory 'https://docs.scipy.org/doc/scipy/objects.inv' not fetchable due to <class 'requests.exceptions.HTTPError'>: 404 Client Error: Not Found for url: https://docs.scipy.org/doc/scipy/objects.inv

Anything else we need to know?

No response

Environment

See RTD