issue_comments

instead of using the Dataset constructor it's actually better to manually convert to a Dataset before passing to xr.merge: ```python arr1 = xr.DataArray([0, 1], dims="x", attrs={"units": "m"}, name="a") arr2 = xr.DataArray([2, 3, 4], dims="y", attrs={"units": "s"})

xr.merge([arr1.to_dataset(), arr2.to_dataset(name="b")], ...) `` that way, the merge is configurable but we avoid thepromote_attrs=True`

I encountered the promote_attrs / merge issue recently in an example similar to @lanougue's above. I'm with @keewis that I would also tentatively support setting promote_attrs=False in merge, but I'm also not that familiar with that part of the codebase and the decisions that went into it.

I want it to basically do nothing to the attrs

I think your workaround should work fine for the example you gave. As an alternative you could also use the Dataset constructor: python xr.Dataset({x0.name: x0, y0.name: y0})

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

that's hard-coded, unfortunately.

because it will not (?) affect the attributes of the variables

that's a misconception: every combine_attrs strategy will affect the attrs on both the variables and the main object. However, "override" was the hard-coded default for variables before the change.

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).

@pydata/xarray, any ideas / opinions?

that makes sense. I'm not sure what syntax we can use for that, though. Maybe also accept a 2-tuple?

It sounds like we should try to add a page to the user-guide section of the docs explaining what combine_attrs (and keep_attrs) do.

When merging an object, all the attrs of the objects to be merge (i.e. all Dataset / DataArray objects that were passed, and separately all variables with the same name) will be passed to a function which does the merging of the attrs. combine_attrs="drop" always makes it return an empty dict while "override" always returns the first attrs dict from the list of dicts it was passed. "drop_conflicts" will go through all those dicts and keeps only those attributes where the values don't mismatch. In other words: that's by design, we simply changed the rules to also apply them to the variables. For examples of how they work:

What I was referring to before was something different: ```python In [2]: arr = xr.DataArray([0, 1], dims="x", attrs={"units": "m"}) ...: arr Out[2]: <xarray.DataArray (x: 2)> array([0, 1]) Dimensions without coordinates: x Attributes: units: m

In [3]: arr.to_dataset(name="a") Out[3]: <xarray.Dataset> Dimensions: (x: 2) Dimensions without coordinates: x Data variables: a (x) int64 0 1

In [4]: arr.to_dataset(name="a", promote_attrs=True) Out[4]: <xarray.Dataset> Dimensions: (x: 2) Dimensions without coordinates: x Data variables: a (x) int64 0 1 Attributes: units: m `` why doesxr.mergeconvert withpromote_attrs=True`?

(I do not understand your comment: how to keep the units on the data instead of in the attributes ?)

have a look at pint-xarray for that (still experimental, but I very much welcome feedback)

yes, I think so: it is strange to merge the data of a variable but not the attributes (or rather, that the merge strategy of variables is hard-coded to "override").

The only thing I would think of as a bug is that the converted datasets would copy the DataArray's attributes to ds.attrs in addition to keeping it on the variable (not sure if I'm missing something, though?). In the example you gave that does not make sense at all: the dataset object does not have units on its own. Edit: you can work around this by keeping the units on the data instead of in the attributes.