issue_comments

I have matplotlib installed.

Here's the output of xr.show_versions() (after rolling back to 0.19):

By "no display available", I meant on a headless server (e.g. WSL2, compute node on slurm cluster).

Digging more into this, this is related to matplotlib/matplotlib#17396 (matplotlib >= 3.4):

• matplotlib tries to automatically select the plotting backend, especially whether or not there is a display to use.
• On Linux, matplotlib < 3.4, this was effectively done by checking if DISPLAY environment variable was set.
• For matplotlib >= 3.4, matplotlib/matplotlib#17396 added additional check to call XOpenDisplay(NULL) to see if X11 is able to connect to the DISPLAY environment variable.
• This was to fix instances where DISPLAY was set but no longer valid. A common example is on slurm (or some other cluster managers) opening a compute node which by default copies all environment variables, including DISPLAY, to a new node.

I experience hanging because my WSL2 setup sets DISPLAY to reference an X11 server that isn't always running. Since the X11 server is on Windows, the DISPLAY refers to a remote address. Apparently, X11 doesn't give up when it isn't able to connect to a remote X11 server, and, so it hangs on that command.

That is for matplotlib >= 3.4. For matplotlib = 3.3 (which is still less than a year old) and xarray=0.20, I get:

• (RedHat on cluster, selects TkAgg backend): is able to import, but fails to plot afterwards
• (WSL2, attempts to select QtAgg backend): fails import (and exits Python!) with message:

``` qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, webgl, xcb.

Aborted ```

This will become a little bit less of an issue when we set the minimum version of matplotlib to 3.4. However, I still think we should revert PR #5794 (PR #6064). It doesn't fix any bug. Before matplotlib >= 3.4, the common-knowledge I had previously seen from writing scripts with headless-use of matplotlib was that we shouldn't import matplotlib.pyplot until we needed it. This was consistent with the previous imports in the plotting functions. Reverting will make it so that errors related to how the plotting environment is set up only take place when users explicitly want to make plots, rather than for all imports of xarray, many of which do not involve any plotting whatsoever.

Wasn't sure what to do about the import_xarray benchmark. Right now, this is just directly reverting previous PR and as such removes it. Might be worth adding it back for benchmarking future PRs.

I see the issue now. Closing the issue, but in case anyone else is figuring this out:

• I initially had this problem with coordinate "a" (index over dimension). In retrospect, since it was a dimension index, it was not chunked. So parallel writes are not safe (since they are not to independent chunks).
• At some point, while constructing my MCVE, I swapped the chunking of "x". Right now, it is not chunked on a, but rather on b. So, parallel writes are not safe (since they are not to independent chunks).
• If I write chunks=(1, None) for the dummy value for x, the example no longer has errors.

In summary, main takeaways are: - check that your chunking aligns with your parallel writes using regions. - dimension coordinates cannot be chunked in zarr (to my knowledge, at least), and so, they do not support parallel writes. Write these either before or after the parallel writes.

Sorry for opening this issue that wasn't a real issue!

We have different test failures than last time. They appear to be happening in tests with time indexes this time. I suspect these failures are again unrelated to the pull request.

The 4 pytest failures per check are taking place in tests/test_plot.py. I suspect that these failures are unrelated to the pull request.

I added a simple test, but not sure it is correctly set up. I wasn't sure about how pytest fixtures worked, so I didn't know if I needed/how to set up a new fixture to test the bugfix.