issue_comments

We dropped Python 3.8 support prior to the Pandas 2 release and have no plans to backport support at this time.

xref: #7765

👏 Congrats @TomNicholas on getting this in! Such an important contribution. 👏

See https://github.com/pydata/xarray/pull/7825 for a PR fixing the outstanding Zarr V3 failures.

Thanks @keewis!

@keewis - you are probably the best person for this task. Can you take on updating our min_deps_check.py script?

Instead, maybe we should extend the support for python versions by about 6 months, to a total of 30 months? That would effectively align us with NEP-29, which is our upper limit anyways since that's what our dependencies follow (even if their releases don't usually happen at exactly that date).

This seems like a good action item to come from this. And seems to align with the thrust of #7777.

@keewis - thanks for the clarifications on the the version policy related to Python 3.8. Very helpful.

Instead, maybe we should extend the support for python versions by about 6 months, to a total of 30 months? That would effectively align us with NEP-29, which is our upper limit anyways since that's what our dependencies follow (even if their releases don't usually happen at exactly that date).

This is an interesting proposal. Worth considering.

@jmccreight - I don't think there is any specific reason this didn't get done. Still open to contributions here if you are interested.

Thanks for following up @28raining. Based on your response, I'm going to close this as it doesn't seem that Xarray is the issue.

This works today using the region parameter in to_zarr. Docs are here: https://docs.xarray.dev/en/stable/user-guide/io.html#appending-to-existing-zarr-stores

@kthyng - any difference when running with parallel=True vs parallel=False?

This doesn't seem like an issue with Xarray. If you change your dockerfile to:

FROM python:3.11.2-slim RUN /usr/local/bin/python -m pip install --upgrade pip RUN pip install xarray RUN pip install rasterio

I suspect you will find that you get the same error on the rasterio line and not on the xarray line.

A second note: Xarray and netcdf4 have not released complete support for python 3.11. For that reason, you may also want to use the python 3.10 image.

This issue was discussed at this week's dev meeting. I will summarize what we discussed:

1. General agreement that propagating encoding through arbitrary operations (e.g. slice, chunk, computation) leads to inconsistent states that are hard to protect against. This often leads to problems when serializing datasets in our backends.
2. The primary benefit of keeping encoding on Xarray objects is the ability to exactly roundtrip datasets. However, this benefit is less obvious after a dataset has been modified.
3. We currently have two APIs for setting encoding (e.g. to_netcdf(..., encoding={...}) and ds.encoding = {...}). We should change this by deprecating setting encoding on Xarray objects using the .encoding property.
4. We can move towards providing utilities that expose a dataset's source encoding (e.g. open_dataset(..., return_encoding=True).

Specific action items that can happen now: - [x] add reset_encoding to Dataset/DatAarray api (https://github.com/pydata/xarray/issues/7686) - [ ] add a DeprecationWarning to the @property.setter for encoding on Dataset/DatAarray/Variable - [ ] document the change in callout in the Xarray user guide.

Longer term action items: - [ ] add option to backend readers to keep / discard interpreted encoding attributes - [ ] disable all encoding propagation by discarding encoding attributes once a Dataset has been modified.

I see how we could do that on the variable but its a bit messy on the Dataset/DataArray. I suggest we wait until this is a requested feature.

In before a user asks for it, should we allow deleting only certain keys like dtype for example?

Not opposed to this but do you think we'll really be asked for this? What sort of API do you envision?

Fair enough. I was extrapolating a bit based on the response to #7496. If someone wants to bite off the writable backends task, I'm all for it.

Should we ping cfgrib to let them know about this change, so they can transfer the removed tests, if they did not do this already?

☝️ @alexamici and @aurghs

I was once a fan of the save_dataset route but I think we've opted to stick with the format specific to_ methods.

As I said in #4817, I think we should pursue the keep_encoding option (in addition to the proposal in this PR).

This seems like a reasonable thing to do. We can likely reuse a lot of the machinery from keep_attrs to make this happen. @snowman2 - is this something you would be up to work on?

See also https://github.com/pydata/xarray/issues/7686. The ideas presented here are also great!

@cefect, @pnorton-usgs, @kthyng - Is this still an issue for you? If so, could you try to run the xarray test suite in #7079 and report back? We haven't been able to trigger the error reported here so we could use some help running the test suite in an "offending" environment.

@margocrawf - thanks for opening this bug report and for providing a complete example demonstrating the issue. Unfortunately (or perhaps fortunately), running your example does not reproduce the same error for me. I have a few questions:

1. Can you add the full output of show_versions? In particular, make sure to include Zarr.
2. Have you tried swapping Zarr for the netcdf4 backend?
3. Are you able to try with a separate environment? If so, try your example above with the latest versions of Xarray/Pandas/Numpy/Zarr and report back if the same issue exists.

@abunimeh - Thanks for opening this issue. Can you expand on the feature a bit more? What API would you like to see? ds.to_netcdf(..., track_order=False)?

I suspect this will need to be treated like invalid_netcdf as it will only apply to the h5netcdf backend:

https://github.com/pydata/xarray/blob/86f3f21ab3d0dff6fdb4a0bccd27c62f9e4a3238/xarray/core/dataset.py#L1892-L1895

_Note: it would be nice if we had backend_kwargs on to_netcdf since the variety of options scipy/netcdf4/h5netcdf support are increasingly different.

@djhoese - I think we're just missing tests for this. No reason it can't go out in the next release.

@lskopintseva - This feature has not been implemented in Xarray (yet). In the meantime, you might find something like this helpful:

python ds = xr.open_dataset("dataset.nc") for v in ds.data_vars: # get variable chunksizes chunksizes = ds[v].encoding.get('chunksizes', None) if chunksizes is not None: chunks = dict(zip(ds[v].dims, chunksizes)) ds[v] = ds[v].chunk(chunks) # chunk the array using the underlying chunksizes

FWIW, I think this would be a nice feature to add to the netcdf4 and h5netcdf backends in Xarray. Contributions welcome!

Agreed. I think we can close this now.

@tomvothecoder - We would welcome a PR to add xCDAT project to the page linked above.

Thanks for the report @derhintze. I agree this seems like a bug. I'm a bit confused by this actually. Our __getitem__ implementation is here:

https://github.com/pydata/xarray/blob/7683442774c8036e0b13851df62bda067b2a65d5/xarray/core/dataset.py#L1418-L1441

and the keys view of a dataset is not hashable:

python isinstance(d.keys(), typing.Hashable) False

Which should be triggering the second @overload in the code above. So I'm not sure what's going on!

Here's a small example to get things started:

python x = aesara.shared(np.random.standard_normal((3, 4))) xda = xr.DataArray(x, dims=('x', 'y')) this currently returns the following error: ```python traceback

ValueError Traceback (most recent call last) Cell In[138], line 2 1 x = aesara.shared(np.random.standard_normal((3, 4))) ----> 2 xda = xr.DataArray(x, dims=('x', 'y'))

File ~/miniforge3/envs/demo-env/lib/python3.10/site-packages/xarray/core/dataarray.py:428, in DataArray.init(self, data, coords, dims, name, attrs, indexes, fastpath) 426 data = _check_data_shape(data, coords, dims) 427 data = as_compatible_data(data) --> 428 coords, dims = _infer_coords_and_dims(data.shape, coords, dims) 429 variable = Variable(dims, data, attrs, fastpath=True) 430 indexes, coords = _create_indexes_from_coords(coords)

File ~/miniforge3/envs/demo-env/lib/python3.10/site-packages/xarray/core/dataarray.py:142, in _infer_coords_and_dims(shape, coords, dims) 140 dims = tuple(dims) 141 elif len(dims) != len(shape): --> 142 raise ValueError( 143 "different number of dimensions on data " 144 f"and dims: {len(shape)} vs {len(dims)}" 145 ) 146 else: 147 for d in dims:

ValueError: different number of dimensions on data and dims: 0 vs 2 ```

This tells me there is a bit of work to do at the core of Aesara's numpy compatibility. Xarray will make frequent references to attributes like data.shape, data.ndim, etc expecting to get numpy-like results.

Thanks all for the discussion. Welcome @brandonwillard, @twiecki, and @rlouf to the Xarray project. And thanks to @rabernat and @TomNicholas for helping orient the conversation.

As a next step, I think it would be fun to try putting an Aesara array into Xarray and see how it goes. In our experience, this process inevitably brings up a few issues where interaction between Xarray and Aesara developers is fruitful.

@adanb13 - thanks for opening this issue. It would be helpful if you can share a sample workflow that produces the memory error that you mention above.

@adanb13 - do you have plans to revisit this PR? If not, do you mind if we close it for now? Based on the comments above, I think an issue discussing the use case and potential solutions would be a good next step.

Closing this as stale and out of date with our current backends. @swnesbitt (or others) - feel free to open a new PR if you feel there is more to do here.

@paigem recently added the following to the open_dataset docstring (https://github.com/pydata/xarray/pull/7438):

In order to reproduce the default behavior of xr.open_zarr(...) use `xr.open_dataset(..., engine='zarr', chunks={})`.

Bring back this old issue since I think there is value in getting something like this in. My suggestion would be to write a zarr-specific _validate_attrs function and use that, rather than stubbing in a special case for zarr in the generic one. @eddienko , I know this has sat for a long time but would you like to try to finish this up?

@hmaarrfk - wondering what your current thoughts on this issue are? Perhaps this can be handled better upstream in zarr-python? Should we close this?

@ianliu - are you interested in finishing up this PR? From my perspective, this seems like a useful feature that would be nice to get in to xarray.

Update: I pushed two new tests to #7488. They are not failing in our test env. If someone that has reported this issue could try running the test suite, that would be super helpful in terms of confirming where the problem lies.

I've opened #7488 which I think has actually exposed a few other failures. I doubt I'll have much time to put into this issue in the near time so anyone should feel free to jump in here.

Thanks @jrbourbeau! I just merged #7458 which moved our isort config to ruff. I suspect pre-commit will be fixed once you move to main.

Hi @alimanfoo! I agree that the current behavior is a bit annoying for users. We may need to develop a refresh_engines function that:

• updates the BACKEND_ENTRYPOINTS dict (it would be nice if entrypoints could help us here)
• clears the list_engines cache
• reinstates the list_engines cache

It would be great if someone could put together a MCVE that reproduces the issue here. We have multiple tests in our test suite that use open_mfdataset with parallel=True, including one that runs against a distributed scheduler and one that runs against the threaded scheduler, so I'm surprised we're not catching this. In any event, the next step would be to develop a test that that triggers the error so we can sort out a fix.

After thinking about this a bit more, I suggest we leave the numpy dtype issue for later. I'd rather not import the private dtypes (at least as part of this PR).

So plan for going forward. @dcherian has already approved this PR. I think it would be good to get one more reviewer to double check things here. Then, assuming things are looking good, I'd like to merge. I will open an issue about the dtype import to track that separately.

@Illviljan, @shoyer, or @keewis - do any of you have suggestions for how to respond to this comment? https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/core/types.py#L57-L62

I plan to leave this as a WIP PR until #7461 is merged. There is a bit of overlap and dropping Python 3.8 will make this much easier to finish up.

I'm doing a bit of an audit on our conditional version logic. A few questions that I don't know how to resolve on my own.

• [ ] _SupportsDType - @headtr1ck, do you have a suggestion for how to handle this comment: https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/core/types.py#L57-L62

• [x] timedeltas - @spencerkclark, do you have a suggestion for how to handle this comment: https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/coding/times.py#L358-L363

• [x] GenericAlias - @Illviljan, do you have a suggestion for how to handle this comment: https://github.com/pydata/xarray/blob/b4e3cbcf17374b68477ed3ff7a8a52c82837ad91/xarray/core/coordinates.py#L31-L40

@pydata/xarray - This PR is ready for discussion / review.

Our minimum versions policy says its time to drop Python 3.8. But do we want to do that?

I'll note that work is already underway to support Python 3.11 (#7316).

Thanks for the report @bmaranville - we can get this fixed asap.

Thanks @stefank0!

I personally favor just copying the code into Xarray and archiving the old repo.

I also lean in this direction. At this point, I see little downside to making this change at this point. My suggestion to import xarray-datatree into xarray was meant low-lift compromise.

I believe this can be closed now. Pynio is on the way out and it seems like we were leaning away from including this anyway.

@pgierz - please feel free to reopen if I have that wrong.

I think the above example can be reduced to just:

python ds = xr.Dataset() ds.to_zarr('test.zarr') ds.to_zarr('test.zarr')

An interesting data point here is that to_netcdf defaults to w mode. And this works fine:

python ds = xr.Dataset() ds.to_netcdf('test.nc') ds.to_netcdf('test.nc')

Personally, I'll make the argument that we should switch (carefully) from -w to w for the default case.

After thinking about this for a bit longer, I think we should be strongly considering dropping source encoding for datasets generated by open_mfdataset. Or, if nothing else, thinking about ways to alert the user that encoding was not consistent across all of the datasets loaded.

Other relevant issues: - https://github.com/pydata/xarray/issues/1614 - https://github.com/pydata/xarray/issues/6323 - https://github.com/pydata/xarray/issues/7039

I took a minute to look into this and think I understand what is going on. First, a little debugging:

python for name in [files[0], files[1], path]: print(name) ds = xr.open_zarr(name, decode_cf=False) print(' > time.attrs', ds.time.attrs) print(' > time.encoding', ds.time.encoding)

``` tmp_dir/2022-09-01T03:00:00.zarr.zip

time.attrs {'calendar': 'proleptic_gregorian', 'units': 'days since 2022-09-01 03:00:00'} time.encoding {'chunks': (1,), 'preferred_chunks': {'time': 1}, 'compressor': Blosc(cname='lz4', clevel=5, shuffle=SHUFFLE, blocksize=0), 'filters': None, 'dtype': dtype('int64')} tmp_dir/2022-09-01T04:00:00.zarr.zip time.attrs {'calendar': 'proleptic_gregorian', 'units': 'days since 2022-09-01 04:00:00'} time.encoding {'chunks': (1,), 'preferred_chunks': {'time': 1}, 'compressor': Blosc(cname='lz4', clevel=5, shuffle=SHUFFLE, blocksize=0), 'filters': None, 'dtype': dtype('int64')} tmp.zarr.zip time.attrs {'calendar': 'proleptic_gregorian', 'units': 'days since 2022-09-01'} time.encoding {'chunks': (1,), 'preferred_chunks': {'time': 1}, 'compressor': Blosc(cname='lz4', clevel=5, shuffle=SHUFFLE, blocksize=0), 'filters': None, 'dtype': dtype('int64')} ```

A few things that I noticed: - the dtype of the time variable is int64. - the units attr is days since ....

open_mfdataset tends to take the units of the first file and doesn't check if all the others agree. It also does not clear out the dtype encoding.

One quick solution here is that you could add

python del dataset['time'].encoding['units'] to the line right after your open_mfdataset call. You could also update the dtype of your time variable to be a float64.

@peterdudfield - have you tried this workflow with the latest version of xarray (2022.12.0)?

This is failing with the following error:

/home/runner/micromamba-root/envs/xarray-tests/lib/python3.10/site-packages/distributed/scheduler.py:120: error: disable_error_code: Invalid error code(s): annotation-unchecked [misc]

Possibly related to https://github.com/pydata/xarray/pull/7319

I changed the title of this issue to reflect the current situation. PyNIO is unlikely to have another release and its compatibility with the Xarray and the rest of the ecosystem is quickly waning. If someone decides to pick up PyNIO maintenance in the future, they can provide backend entrypoint.

Maybe we should remove the pynio backend tests all together since they will be skipped anyway if no env has pynio enabled anymore?

I think we should keep them in the test suite as long as the backend is in the code. Although we able to install pynio in our test envs, I suspect it is still possible to construct an environment centered around the pynio that would still work.

This is ready to merge once https://github.com/pydata/xarray/pull/7300 is in.

I suggest we plan to remove the pynio backend in a future release. The project is very likely dead.

https://github.com/NCAR/pynio/issues/53

@grlee77, @rabernat, @joshmoore, and others - I think this is ready to review and/or merge. The Zarr-V3 tests are active in the CI Upstream / upstream-dev GitHub Action. The test failure on readthedocs is unrelated to this PR.

@grlee77 - I'm curious if you are planning to return to this PR or if it would be helpful if someone brought it to completion?

A separate issue is that consolidated metadata isn't in the core Zarr v3 spec, so we will need to have a Zarr Enhancement Proposal to formally define how the metadata should be stored. In the experimental API, it behaves as for v2 and is stored at /meta/root/consolidated by default.

I think it would be fine to disallow consolidated metadata for v3 until there is a spec in place. This is going to be experimental for some time so I don't see the harm in raising an error when consolidated=True and version=3. I think this is better than guessing what the v3 extension will specify.

Thanks @hmaarrfk - this looks great.

@asmeurer recently pointed me to https://data-apis.org/array-api-tests/. Would that be useful here?

While there is overlap in the behavior here, I've always thought of these two methods as having distinct applications. .compute() is a Dask collection method. .load(), which predates Xarray's Dask integration, was originally meant to load data from our lazy loading backend arrays (e.g. a netCDF file).

Edit: up until I read this issue, I somehow assumed compute would only work with dask while load would also load our lazy array implementation into memory. Not sure how I got that impression, but maybe that's another argument to remove / align load?

This was my impression as well but now I understand that the primary difference is that load is inplace while compute is not.

Hi @lumbric - thanks for the report. Though its often challenging when coming from complicated workflows, getting to a MCVE is really the only way to sort out what is going wrong here.

A few suggestions that will hopefully help you get there:

• Try running your calculation using the synchronous dask scheduler. Dask's graph execution order is not always deterministic so sometimes leads to the conclusion that errors are not reproducible.
• Try reconstructing a similar workflow with dummy data.

FWIW, the error you are getting tells me that you have an Index/Coordinate with duplicate values in it. Are you sure that is not possible?

Huge! Amazing effort here @benbovy!

It would be nice to avoid this process but I think we need to keep it. Without extract_zarr_variable_encoding and checks against a valid set of options, we have no way to filter out encoding keys that do not apply to the backend. By way of an example:

python In [1]: import xarray as xr In [2]: ds = xr.tutorial.open_dataset('rasm').chunk('100mb') In [3]: ds.Tair.encoding Out[3]: {'source': '/Users/jhamman/Library/Caches/xarray_tutorial_data/eee06791cc19e59f074155a82a7ffe90-rasm.nc', 'original_shape': (36, 205, 275), 'dtype': dtype('float64'), '_FillValue': 9.969209968386869e+36, 'coordinates': 'yc xc'}

Passing most of these to zarr.create would result in a UserWarning. We could inpspect zarr.create to pull the list of valid arguments but I think it is probably cleaner to just list the expected arguments as we do.

Thanks @tomwhite for making this change!

To be fair, ds.info is not 100% CDL, but it's darn close.

I think making ds.info CDL compliant would be a great feature addition.

Describe alternatives you've considered

Some kind of schema object that can be used to validate or generate an xarray Dataset, but does not contain any data.

You may be interested in xarray-schema then. We're actively working on / using this project and would be more than happy to think about how a cdl-like schema fits in there.

@ax3l - The packaging dependency should be resolved in https://github.com/pydata/xarray/pull/6207.

This is ready to merge. @max-sixty - whenever you are ready, go ahead and merge and make the release.

Thanks @Peder2911 for opening a PR. The discussion and changes in #6207 are a bit further along so I suggest we focus efforts there.

@pydata/xarray - we should try to get this merged and a new release up ASAP as bug reports are starting to pile up. I've pushed changes to the CI configs, documentation, and elsewhere. I've also pulled in the recent changes on main which should hopefully fix the failing CI in the first commit.

Also, thanks @s-weigand for opening this PR and raising the issue.

After thinking on this one a bit, I'm back to thinking we should zero-pad the months. I don't think there is a clear right choice here, with both options offering pros/cons. Thanks @ksunden in particular for sharing your perspective). I suggest we try this in 2022.02.0. See #6214 for more details.

Interesting insights @ksunden, thanks for sharing!

Do others have thoughts here? I would support stripping the leading zeros from the MM part of the version string in favor of consistency here.

It is worth mentioning that, specifically when using Zarr with fsspec, you have multiple layers of caching available.

1. You can ask fsspec to cache locally:

python path = 's3://hrrrzarr/sfc/20211124/20211124_00z_fcst.zarr/surface/PRES' ds = xr.open_zarr('simplecache::'+path) (more details on configuration: https://filesystem-spec.readthedocs.io/en/latest/features.html#caching-files-locally)

1. You can ask Zarr to cache chunks as they are read:

python mapper = fsspec.get_mapper(path) store = LRUStoreCache(mapper, max_size=1e9) ds = xr.open_zarr(store)

(more details on configuration here: https://zarr.readthedocs.io/en/stable/api/storage.html#zarr.storage.LRUStoreCache)

1. Configure a more complex mapper/cache using 3rd party mappers (i.e. Zict)

perhaps @martindurant has more to add here?

@chiaweh2 - a PR to improve the documentation would certainly be welcome. Do you think it makes sense to add this to the docstring or to the user guide page on IO (https://xarray.pydata.org/en/stable/user-guide/io.html#chunk-based-compression)?

+1 on making this change. However, just to note, Pandas seems to still have the the interpolation argument (https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.quantile.html) so we will be introducing an inconsistency there.

Related to the Pandera integration, we are prototyping the xarray schema validation functionality in the xarray-schema project.

I'm also late to the party but I would say I fall squarely in the Dataset is a dict-like camp. If we remove __bool__, should we also remove __len__? Basically, everything @dopplershift aligns with my perspective here.

@pydata/xarray and others - we're going to cancel the next regularly scheduled meeting (Dec. 22, 2021) so everyone can take a break. We'll be back Jan. 5, 2022.

@andy-sweet - please do join the next call. I've added it to the meeting agenda.

Hi @sofroniewn - This is certainly something we still want to work on (see this section of our current roadmap and a more detailed proposal that included work in this area). I actually think the relevant part of the linked proposal is the best we have for a working plan here (text copied from doc below):

Xvariable: New lightweight Variable API (labeled arrays without coordinates)

This work area is about cleaning up Xarray’s internals, and allowing our low-level “Variable” data structure to be usable by other projects in the scientific Python ecosystem. We have identified the following key tasks and deliverables:

a. Formalize Xarray’s contract for valid data inside “Variable”, and remove/replace some legacy features that would be hard to justify for a generic library: 1. Move the “encoding” attribute from “Variable” onto a new “duck array” class that can be used inside a “Variable” (#5082) 2. Expose Xarray’s internal model for “explicit array indexing” as a public API. Xarray uses this feature because supporting the full complexity of NumPy’s full indexing API is hard for many array implementations.

b. Separate out and possibly rename/re-brand to Xvariable parts of Xarray internals into new projects. This will increase their visibility, find new users for these tools and improve the maintainability of Xarray itself. 1. The ”Variable” class will move into a separate project that only depends upon NumPy, and that Xarray in-turn will depend upon. We hope this project will be of interest to users interested in simpler tools than Xarray (#3981). 2. The new package will support indexing and a limited series of other operations lazily on arrays loaded from disk or remote storage, without loading the entire array into memory. This project is of interest to other projects such as Napari (#5081).

c. API stabilization, code consolidation and maintenance of the external project.

We have a bi-weekly developer call on Wednesday mornings (#4001), one idea would be devote 10-15 minutes of our next meeting to this topic. Is that something you and/or @andy-sweet would be up for joining?

Thought I would drop a related note here. Gcsfs just added support for fixed-key metadata: https://github.com/fsspec/gcsfs/pull/429. So if you are testing out different fsspec/gcsfs options for caching, make sure you are using gcsfs==2021.11.0.

closed via https://github.com/rasterio/rasterio/pull/2141

I plan to merge this tomorrow unless I hear otherwise.

Thanks @rabernat for opening up this issue. I think now that the refactor for read support is completed, it is a great time to discuss the opportunities for adding write support to the plugin interface.

pinging @aurghs and @alexamici since I know they have some thoughts developed here.

Hi @dimzog. Thank you for taking time to report this issue. However, it seems to me that this would be better reported on the geopandas and/or rioxarray issue tracker.

Thanks @TomNicholas! I've just been starting to look into this. I'm going to give it a spin and would be happy to help with your numbers 3 and 4.

Thanks @chrisroat - let's see if @rabernat or @shoyer has an opinion here then.

Thanks @chrisroat for the PR. This looks great. I do think we should add an entry in whats-new.rst though. Once that is done, I'll merge this.

@grouny - thanks for this PR! And I see that this is your first time contributing to Xarray -- Welcome!

This fix you propose looks great. Apart from the linter complaining about some whitespace, I think this would benefit from a simple test. Would you mind adding a test to xarray/tests/test_backends.py?

Q for @snowman2 - is rioxarray handling complex datatypes in this way?

@chrisroat - apologies for letting this sit for so long without a review. If you are interested in finishing it up, we may need to open a new PR to account for the closure here. If so, please ping me directly and I'll get on the review asap.

@keewis - did we mean to close this or was this related to the switch to main (#5516)?

pinging @dcherian and/or @crusaderky who may have thoughts on this PR.

Something seems to have changed in our regular Zoom room. For this week, let's use this Zoom link.

Thanks for the report. Can you say more about how you installed Xarray?