@stanwest how's that?

That looks great to me.

@stanwest Can you suggest how to fix this merge conflict please?

Sure. I recommend the following before the return statement in xarray.core.dataset._get_chunk:

```python

Warn where requested chunks break preferred chunks, provided that the variable

contains data.

if var.size: for dim, size, chunk_sizes in zip(dims, shape, chunk_shape): try: preferred_chunk_sizes = preferred_chunks[dim] except KeyError: continue # Determine the stop indices of the preferred chunks, but omit the last stop # (equal to the dim size). In particular, assume that when a sequence # expresses the preferred chunks, the sequence sums to the size. preferred_stops = ( range(preferred_chunk_sizes, size, preferred_chunk_sizes) if isinstance(preferred_chunk_sizes, Number) else itertools.accumulate(preferred_chunk_sizes[:-1]) ) # Gather any stop indices of the specified chunks that are not a stop index # of a preferred chunk. Again, omit the last stop, assuming that it equals # the dim size. breaks = set(itertools.accumulate(chunk_sizes[:-1])).difference( preferred_stops ) if breaks: warnings.warn( "The specified Dask chunks separate the stored chunks along " f'dimension "{dim}" starting at index {min(breaks)}. This could ' "degrade performance. Instead, consider rechunking after loading." ) ```

For my understanding and curiosity, what are the perceived benefits of a separate function to warn about splitting the preferred chunks? It seemed better to me to avoid the overhead of the function call and the unnecessary internal interface, particularly considering that the function was private, had only one caller, and was so closely related to its caller.

Thank you for this fix! It looks good to me.

Thanks for the review and approval. Is this PR ready to trade the "needs review" label for the "plan to merge" label?

Thanks for accepting the fix!

For the sake of cross-references, #6249 originated the test modified here.

Okay. I've committed the changes.

Thanks for your PR - we are definitely interested to make this work on windows.

👍

Instead of adding :okexcept: could we explicitly close the offending files?

It seems that we can, although closing all of the references was non-trivial in "user-guide/io.rst". Please see the diffs below for the two files with the most extensive changes. Within each document, I've tried to delete the files as early as possible to keep that code close to the last use of the file.

We can also straightforwardly remove the "rasm.zarr" directory:

Is that general approach agreeable? If so, I'll commit the changes for further comment and review.

Following #3270, on which this PR builds, I added a "whats-new" entry in the "Documentation" section.

It seems that readthedocs lacks support for the CONDA_EXE environment variable. I added a fall-back to call merely "conda".

Note that da.plot(x="lon", y="lat") and da.plot(x="lon", y="v") both work. So you have at least a workaround.

Yes. I didn't readily see that I needed to specify both x and y, partly because of the documentation and partly because I was deceived by the traceback. (Although xr.core.utils.infix_dims() raises the exception, xr.plot.utils._infer_xy_labels() causes the problem, and the responsible calls are separated by tens of lines in xr.plot.plot._plot2d().

But yes I think it would be good to extend the logic to work when a non-dimension coordinate is passed.

I agree that, if xarray is going to guess, handling non-dimension coordinates would be an improvement. It might be specified to work only with 1-D coordinates and to do nothing for multi-dimensional coordinates.

Alternatively, is it at all preferable to remove the guessing feature? Although the behavior has been present for years, I found mention of it in the documentation only in "What's New." The motivating use case in #1290 could have been addressed instead simply with z.transpose().plot(), which the guessing causes under the hood anyway.