• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

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

```python import matplotlib.pyplot as plt import xarray as xr

airtemps = xr.tutorial.open_dataset("air_temperature") air = airtemps.air - 273.15 air1d = air.isel(lat=10, lon=10)

plt.figure() air1d.plot() ``` Before:

After:

What happened?

The CI seems to consistently crash on test_units.py now: =========================== short test summary info =========================== FAILED xarray/tests/test_units.py::TestVariable::test_aggregation[int32-method_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestVariable::test_aggregation[int32-method_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[float64-function_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[float64-function_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-function_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-function_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-method_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_aggregation[int32-method_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_unary_operations[float64-round] - TypeError: no implementation found for 'numpy.round' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataArray::test_unary_operations[int32-round] - TypeError: no implementation found for 'numpy.round' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataset::test_aggregation[int32-method_max] - TypeError: no implementation found for 'numpy.max' on types that implement __array_function__: [<class 'pint.util.Quantity'>] FAILED xarray/tests/test_units.py::TestDataset::test_aggregation[int32-method_min] - TypeError: no implementation found for 'numpy.min' on types that implement __array_function__: [<class 'pint.util.Quantity'>] = 12 failed, 14880 passed, 1649 skipped, 146 xfailed, 68 xpassed, 574 warnings in 737.19s (0:12:17) = For more details: https://github.com/pydata/xarray/actions/runs/5438369625/jobs/9889561685?pr=7955

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

What happened?

The upstream CI has been failing for a while. Here's the latest: https://github.com/pydata/xarray/actions/runs/5501368493/jobs/10024902009#step:7:16

python Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/runner/work/xarray/xarray/xarray/__init__.py", line 1, in <module> from xarray import testing, tutorial File "/home/runner/work/xarray/xarray/xarray/testing.py", line 7, in <module> import numpy as np ModuleNotFoundError: No module named 'numpy'

Digging a little in the logs ``` Installing build dependencies: started Installing build dependencies: finished with status 'error' error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully. │ exit code: 1 ╰─> [3 lines of output] Looking in indexes: https://pypi.anaconda.org/scipy-wheels-nightly/simple ERROR: Could not find a version that satisfies the requirement meson-python==0.13.1 (from versions: none) ERROR: No matching distribution found for meson-python==0.13.1 [end of output] ```

Might be some numpy problem?

Should the CI be robust enough to handle these kinds of errors? Because I suppose we would like to get the automatic issue created anyway?

Use https://pypi.anaconda.org/scientific-python-nightly-wheels/simple/ instead.

• [x] Closes #7969

A simple refactor to make it easier to retrieve the proper paths that open_mfdataset uses and passes on the engine.

I've been thinking how to make use of DataTree and one idea I wanted to try was: * Open file (using_find_absolute_path). * Get all groups in the file. * For each group run xr.open_mfdataset(..., group=group)

Fixes typing errors when using newest mypy version.

• [x] Closes #7270

Is your feature request related to a problem?

Use more up-to-date typing styles on all files. Will reduce number of imports and avoids big diffs when doing relatively minor changes because pre-commit/pyupgrade has been triggered somehow.

Related to #6240

Describe the solution you'd like

Add from __future__ import annotations on files with a lot of typing. Let pyupgrade do the rest.

Describe alternatives you've considered

No response

Additional context

No response

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

• Workaround for Pull Request Labeler The PR labeler keeps removing manually added labels. xref: https://github.com/actions/labeler/issues/112
• ASV benchmarks starts also when topic-performance label is added now. Bot is allowed to change this one, but not run-benchmarks.

Fix some issues with scatter plots: * Always use markersize widths for scatter. * Fix issue with .values_unique not returning the same values as .values * Added more type hints to _Normalize, some rework had to be done to make mypy pass.

xref: #6778

Clean up a little in preparation for #6059.

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

xref: #6244

Inspired by #5734, remove the non-bottleneck build and instead use xr.set_options on the relevant tests. This makes the report much more readable and reduces testing time quite a bit since everything isn't accelerated by bottleneck.

• [x] Passes pre-commit run --all-files

Minor change to align with other booleans.

ref #5582

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

While trying to figure out which types are allowed in #5678 I felt that the set_options docstring was rather hard to read. Moving it to typical numpy docstring style helped at least for me.

Allow controlling the randomness of the dataset. It's difficult to catch issues with the dataset if it always changes each run.

Make sure name is a string. Use the same .format method as in _get_units_from_attrs to convert to string.

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

What happened?

xr.concat removes datetime information and can't concatenate the arrays because they don't have compatible types anymore.

What did you expect to happen?

Succesful concatenation with the same type.

Minimal Complete Verifiable Example

```Python import numpy as np import xarray as xr from datetime import datetime

month = np.arange(1, 13, 1) data = np.sin(2 * np.pi * month / 12.0)

darray = xr.DataArray(data, dims=["time"]) darray.coords["time"] = np.array([datetime(2017, m, 1) for m in month])

darray_nan = np.nan * darray.isel(**{"time": -1}) darray = xr.concat([darray, darray_nan], dim="time") ```

Relevant log output

```Python Traceback (most recent call last):

File "<ipython-input-15-31040255a336>", line 2, in <module> darray = xr.concat([darray, darray_nan], dim="time")

File "c:\users\j.w\documents\github\xarray\xarray\core\concat.py", line 244, in concat return f(

File "c:\users\j.w\documents\github\xarray\xarray\core\concat.py", line 642, in _dataarray_concat ds = _dataset_concat(

File "c:\users\j.w\documents\github\xarray\xarray\core\concat.py", line 555, in _dataset_concat combined_idx = indexes[0].concat(indexes, dim, positions)

File "c:\users\j.w\documents\github\xarray\xarray\core\indexes.py", line 318, in concat coord_dtype = np.result_type(*[idx.coord_dtype for idx in indexes])

File "<array_function internals>", line 5, in result_type

TypeError: The DType <class 'numpy.dtype[datetime64]'> could not be promoted by <class 'numpy.dtype[int64]'>. This means that no common DType exists for the given inputs. For example they cannot be stored in a single array unless the dtype is object. The full list of DTypes is: (<class 'numpy.dtype[datetime64]'>, <class 'numpy.dtype[int64]'>) ```

Anything else we need to know?

Similar to #6384.

Happens around here:

https://github.com/pydata/xarray/blob/728b648d5c7c3e22fe3704ba163012840408bf66/xarray/core/concat.py#L535

Environment

A while back GitHub made it so that new contributors cannot trigger GitHub Actions workflows and a maintainer has to hit "Approve and Run" every time they push a commit to their PR. This is rather annoying for both the contributor and the maintainer as the back and forth takes time.

It however seems possible to relax this constraint: https://twitter.com/metcalfc/status/1448414192285806592?t=maeChQZTSUh2Ph0YFk-hGA&s=19

Shall we relax this constraint?

ref: https://github.com/dask/community/issues/191

Copy pasting the examples in http://xarray.pydata.org/en/stable/internals/how-to-add-new-backend.html resulted in crashes. Make the docs copy/paste friendly by removing the self arguments.

Example: ```python expected = xr.Dataset( dict(a=2 * np.arange(5)), coords=dict(x=("x", np.arange(5), dict(units="s"))) )

class CustomBackend(xr.backends.BackendEntrypoint): def open_dataset( self, filename_or_obj, drop_variables=None, **kwargs, ): return expected.copy(deep=True)

xr.open_dataset("fake_filename", engine=CustomBackend) TypeError: open_dataset() missing 1 required positional argument: 'filename_or_obj' This works if self is removed:python expected = xr.Dataset( dict(a=2 * np.arange(5)), coords=dict(x=("x", np.arange(5), dict(units="s"))) )

class CustomBackend(xr.backends.BackendEntrypoint): def open_dataset( filename_or_obj, drop_variables=None, **kwargs, ): return expected.copy(deep=True)

xr.open_dataset("fake_filename", engine=CustomBackend) <xarray.Dataset> Dimensions: (a: 5, x: 5) Coordinates: * a (a) int32 0 2 4 6 8 * x (x) int32 0 1 2 3 4 Data variables: empty ```

• [x] Passes pre-commit run --all-files

What happened: When interpolating a dataset with >2000 dask variables a lot of time is spent in da.unifying_chunks because da.unifying_chunks forces all variables and coordinates to a dask array. xarray on the other hand forces coordinates to pd.Index even if the coordinates was dask.array when the dataset was first created.

What you expected to happen: If the coords of the dataset was initialized as dask arrays they should stay lazy.

Minimal Complete Verifiable Example:

```python import xarray as xr import numpy as np import dask.array as da

a = np.arange(0, 2000) b = np.core.defchararray.add("long_variable_name", a.astype(str)) coords = dict(time=da.array([0, 1])) data_vars = dict() for v in b: data_vars[v] = xr.DataArray( name=v, data=da.array([3, 4]), dims=["time"], coords=coords ) ds0 = xr.Dataset(data_vars) ds0 = ds0.interp( time=da.array([0, 0.5, 1]), assume_sorted=True, kwargs=dict(fill_value=None), ) ```

Anything else we need to know?: Some thoughts: * Why can't coordinates be lazy? * Can we use dask.dataframe.Index instead of pd.Index when creating IndexVariables? * There's no time saved converting to dask arrays in missing.interp_func. But some time could be saved if we could convert them to dask arrays in xr.Dataset.interp before the variable loop starts. * Can we still store the dask array in IndexVariable and use a to_dask_array()-method to quickly get it? * Initializing the dataarrays will still be slow though since it still has to force the dask array to pd.Index.

Environment:

What happened: xarray feels very unresponsive when using datasets with >2000 data variables because it has to print all the 2000 variables everytime you print something to console.

What you expected to happen: xarray should limit the number of variables printed to console. Maximum maybe 25? Same idea probably apply to dimensions, coordinates and attributes as well,

pandas only shows 2 for reference, the first and last variables.

Minimal Complete Verifiable Example:

```python import numpy as np import xarray as xr

a = np.arange(0, 2000) b = np.core.defchararray.add("long_variable_name", a.astype(str)) data_vars = dict() for v in b: data_vars[v] = xr.DataArray( name=v, data=[3, 4], dims=["time"], coords=dict(time=[0, 1]) ) ds = xr.Dataset(data_vars)

Everything above feels fast. Printing to console however takes about 13 seconds for me:

print(ds) ```

Anything else we need to know?: Out of scope brainstorming: Though printing 2000 variables is probably madness for most people it is kind of nice to show all variables because you sometimes want to know what happened to a few other variables as well. Is there already an easy and fast way to create subgroup of the dataset, so we don' have to rely on the dataset printing everything to the console everytime?

Environment: