issue_comments

Same issue here. I installed xarray with conda/mamba (not a dev install).

``` INSTALLED VERSIONS

commit: None python: 3.11.3 | packaged by conda-forge | (main, Apr 6 2023, 08:57:19) [GCC 11.3.0] python-bits: 64 OS: Linux OS-release: 3.10.0-1160.42.2.el7.x86_64 machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_US.UTF-8 LOCALE: ('en_US', 'UTF-8') libhdf5: 1.14.0 libnetcdf: 4.9.2

xarray: 2023.4.2 pandas: 2.0.1 numpy: 1.24.3 scipy: 1.10.1 netCDF4: 1.6.3 h5netcdf: None h5py: None zarr: 2.14.2 dask: 2023.4.1 distributed: None pip: 23.1.2 IPython: 8.13.1 ```

Edit: downgrading to 2023.4.0 solved the issue.

how did you set up your environment? This works for me: sh mamba create -n test python=3.11 xarray dask netcdf4 pooch ipython mamba activate test ipython python xr.tutorial.open_dataset("rasm", chunks={})

Interestingly enough, though, is that you should only see this with xarray=2023.5.0, while your environment claims to have xarray=2023.4.2. It seems there is something wrong with your environment?

Solution for those who just found this issue:

Just re-install xarray. pip install -e . is sufficient. Re-installing any way through pip/conda should register the dask chunkmanager entrypoint.

@Illviljan I brought this up in the xarray team call today and we decided that since this only affects people who have previously cloned the xarray repository, are using a development install, and then updated by pulling changes from main; this problem only affects maybe ~10-20 people worldwide, all of whom are developers who are equipped to quickly solve it.

I'm going to add a note into the what's new entry for this version now - if you think we need to do more then let me know.

EDIT: I added a note to whatsnew in https://github.com/pydata/xarray/commit/69445c62953958488a6b35fafd8b9cfd6c0374a5, and updated the release notes.

The only reason I didn't separate the chunkmanager entry points into local and other entry points was simplicity of code.

I didn't realise that might make a difference when it came to whether or not you have to pip install - I assumed that adding a new type of entry point would require re-installing no matter how I implemented it. If that's not the case perhaps we should adjust it (and re-release).

Nope, I have not tried that. I suspect things will just self heal then considering the CI without understanding the root cause.

Looking at the backends; we initialize a dict here: https://github.com/pydata/xarray/blob/d8ec3a3f6b02a8b941b484b3d254537af84b5fde/xarray/backends/common.py#L435

Stores each of our entrypoints like this: https://github.com/pydata/xarray/blob/d8ec3a3f6b02a8b941b484b3d254537af84b5fde/xarray/backends/h5netcdf_.py#L438

Then we append the local and other entrypoints together here: https://github.com/pydata/xarray/blob/d8ec3a3f6b02a8b941b484b3d254537af84b5fde/xarray/backends/plugins.py#L106-L116

But load_chunkmanagers doesn't really seem to append from a dict: https://github.com/pydata/xarray/blob/d8ec3a3f6b02a8b941b484b3d254537af84b5fde/xarray/core/parallelcompat.py#L48-L62

Why do the backends use the BACKEND_ENTRYPOINTS strategy? To avoid these cases? Or something else?

Yes, but I'm wondering what functional difference is that making here?

Have you tried doing the local pip install of the xarray dev version again? I.e. pip install -e . from the xarray folder.

The CI recreates its entire environment all the time and I don't?

```python from xarray.core.parallelcompat import list_chunkmanagers

list_chunkmanagers() Out[1]: {} ```

Hmm, it's acting as if dask is not installed/importable. Any idea what's different about your setup vs the xarray CI?

Yes daskmanager is also registered via a different entry point, but that should already be set up to happen by default.

To see which chunk managers it can find you can call

```python from xarray.core.parallelcompat import list_chunkmanagers

list_chunkmanagers() ```

I expect it will return an empty list in your case, but that's the code we should be trying to debug on your system.

Our backends are stored in a dict like this: BACKEND_ENTRYPOINTS["h5netcdf"] = ("h5netcdf", H5netcdfBackendEntrypoint). Is it something similar daskmanager needs to do?

cc @TomNicholas