Hi @Illviljan @keewis,

I have added tests and marked them as xfail

Accoriding to pytest docs

A skip means that you expect your test to pass only if some conditions are met, otherwise pytest should skip running the test altogether. Common examples are skipping windows-only tests on non-windows platforms, or skipping tests that depend on an external resource which is not available at the moment (for example a database).

An xfail means that you expect a test to fail for some reason. A common example is a test for a feature not yet implemented, or a bug not yet fixed. When a test passes despite being expected to fail (marked with pytest.mark.xfail), it’s an xpass and will be reported in the test summary.

This case seems exactly what xfail is meant for. But feel free to change this.

Do the slice plots work with non-dimension coordinates? If so, we should maybe add a test with pint for that, too: units in non-dimension coordinates are not stripped.

It seems so, but it raises a pint warning despite the code producing the intended figure:

```python import xarray as xr import numpy as np import matplotlib.pyplot as plt import pytest pint = pytest.importorskip("pint") unit_registry = pint.UnitRegistry(force_ndarray=True)

coord_unit, coord_attrs = (unit_registry.m, {})

def test_units_in_slice_line_plot_labels_isel(): arr = xr.DataArray( name="var_a", data=np.array([[1, 2], [3, 4]]), coords=dict( a=("x", np.array([5, 6]) * coord_unit, coord_attrs), b=("y", np.array([7, 8])), ), dims=("x", "y"), ) arr.isel(x=0).plot(marker="o") assert plt.gca().get_title() == "a = 5 [meter]" return arr

test_units_in_slice_line_plot_labels_isel() ```

I would appreciate a lot if we keep the scope of this PR to what I have contributed so far, I am running out of bandwidth in the project I am involved and won't be able to add much more to this PR.

Kind regards, Victor

Just checked and this cannot be tested for pint units, there is already a comment in there explaining this:

```python

TODO make coord a Quantity once unit-aware indexes supported"

``` Since the slice units come from a coordinate these units can't be pint units (at least not yet).

I added a new test for the units in the title of a slice line plot, also added the same comment about pint units.

Who should I ping for the PR approval?

This is great, thanks @caenrigen !

It just needs a couple of tests - ideally one for basic behaviour like you've shown in your example (which should probably live here), and another checking that it works with pint units like we added in #5561.

Hi @TomNicholas!

Thank you for the input and guidance, will work on adding the tests 🙂

Cheers

@keewis thank you for the reply

To fix this, I would vote for not using promote_attrs=True in merge (low confidence vote, though, I'm sure there was a reason for that). We could also try to allow specifying separate strategies for main object and variables, but that looks somewhat complicated (and I'm still not sure what syntax we could use for that).

Does this mean that my workaround is not fully working as I would like it to? (I want it to basically do nothing to the attrs)

Is it possible at the moment to pass promote_attrs=False to xr.merge()?

Hey guys! First of all thank you for the work on maintaining this package 😃

I am running into the same issue and it is partially blocking an open-source package (used in experimental quantum computing) from adopting the latest version of xarray.

For our typical dataset this happens:

python import xarray as xr import numpy as np x0 = xr.DataArray(data=np.ones(5), name="x0", attrs={ 'name': 'x', 'long_name': 'X position', 'units': 'm', 'batched': False}) y0 = xr.DataArray(data=np.ones(5), name="y0", attrs={ 'name': 'y', 'long_name': 'Y position', 'units': 'm', 'batched': True}) ds = xr.merge([x0, y0]) print(ds)

bash <xarray.Dataset> Dimensions: (dim_0: 5) Dimensions without coordinates: dim_0 Data variables: x0 (dim_0) float64 1.0 1.0 1.0 1.0 1.0 y0 (dim_0) float64 1.0 1.0 1.0 1.0 1.0 Attributes: name: x long_name: X position units: m batched: False

As default behavior this is totally unexpected because the variables attributes have nothing to do with the dataset itself. I am just trying to put all my data in a single container. (Am i using the wrong function for this?)

And second, combine_attrs has no option for "do nothing" which was the behavior in xarray 0.17.0. I noticed the current master brach allows passing a function but not sure if that solves the problem. The "drop" option indeed acts in very weird way, I tried it in the hope that it will drop attrs on the resulting dataset instead of affecting the attributes of the variables.

My suggestion is to do nothing by default, i.e. combine_attrs = None, simply does not try to combine the attribute in any way.

I understand there might be cases where combining the attributes makes sense, so maybe my suggestion only applies when only DataArrays objects are merged into a Dataset (If i recall correctly the "what's new" list, this will be already enforced in 0.18.3).

Hope my use case helps this discussion.

In the meantime the workaround seems to be: combine_attrs = "override" (because it will not (?) affect the attributes of the variables) + and wipe attrs afterwards with dataset.attrs = dict():

python import xarray as xr import numpy as np x0 = xr.DataArray(data=np.ones(5), name="x0", attrs={ 'name': 'x', 'long_name': 'X position', 'units': 'm', 'batched': False}) y0 = xr.DataArray(data=np.ones(5), name="y0", attrs={ 'name': 'y', 'long_name': 'Y position', 'units': 'm', 'batched': True}) ds = xr.merge([x0, y0]) ds.attrs = dict() print(ds) print("===") print(ds.x0)

```bash

<xarray.Dataset> Dimensions: (dim_0: 5) Dimensions without coordinates: dim_0 Data variables: x0 (dim_0) float64 1.0 1.0 1.0 1.0 1.0 y0 (dim_0) float64 1.0 1.0 1.0 1.0 1.0 === <xarray.DataArray 'x0' (dim_0: 5)> array([1., 1., 1., 1., 1.]) Dimensions without coordinates: dim_0 Attributes: name: x long_name: X position units: m batched: False ```

@caenrigen thanks for the issue. Would you be up for fixing this with a PR?

Unfortunately out of bandwidth currently, this came out when addressing #4981 so I reported it as suggested.

For anyone facing the issue, installing netcdf4 solves the issue as a temporary fix

Hey, guys!!

Does any of you have backends expertise? A review of PR #4986 from someone with knowledge on the topic would be appreciated so much 🥺 One collaborator already approves the hotfix but is waiting for an additional approval

Kind regards

Very cool to hear you're using xarray in your quantum computing framework!

This sounds like a reasonable change to me. A PR would indeed be very welcome!

PR created https://github.com/pydata/xarray/pull/4986

@keewis thank you for the guidance! changes applied ✅ Looking forward to the merge 🤩

but the tests (without any changes to the code) fail on my local clone of the repo so it would be more difficult to go through a PR for this.

Can you post an issue about that with an error message?

You can always make your change, and open a PR, and have the CI check it :) . PRs are very welcome!

Done https://github.com/pydata/xarray/issues/4985