html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/7199#issuecomment-1482360438,https://api.github.com/repos/pydata/xarray/issues/7199,1482360438,IC_kwDOAMm_X85YWwZ2,226037,2023-03-24T07:17:16Z,2023-03-24T07:17:16Z,MEMBER,"@dcherian note that _cfgrib_ is now maintained by @iainrussell, anyway I agree that the in-tree driver can be safely removed.

@headtr1ck I don't think any deprecation is needed, the `engine=""cfgrib""` should select the external backend if available and fall back on the internal one only for ancient versions of _cfgrib_.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1419825696
https://github.com/pydata/xarray/issues/6514#issuecomment-1109923473,https://api.github.com/repos/pydata/xarray/issues/6514,1109923473,IC_kwDOAMm_X85CKBaR,226037,2022-04-26T15:14:24Z,2022-04-26T15:14:24Z,MEMBER,"The *Compatibility Note* I linked above appears to point out the the `entry_points(group=""xarray.backends"")` is available since Python 3.6, so we not need the versione check at all.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1215082284
https://github.com/pydata/xarray/issues/6512#issuecomment-1109408693,https://api.github.com/repos/pydata/xarray/issues/6512,1109408693,IC_kwDOAMm_X85CIDu1,226037,2022-04-26T06:42:50Z,2022-04-26T06:42:50Z,MEMBER,"> Should we by default use a temp file? or is there some benefit to retaining the index file locally? (asking as someone with very little context

Opening the a GRIB for the first time requires reading the whole file and saving the index to disk makes all subsequent open much faster. I took the decision to default to writing, but IMO the real issue is that it is not well documented how to switch it off 😅 ","{""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1214654475
https://github.com/pydata/xarray/issues/6512#issuecomment-1109399455,https://api.github.com/repos/pydata/xarray/issues/6512,1109399455,IC_kwDOAMm_X85CIBef,226037,2022-04-26T06:29:57Z,2022-04-26T06:30:04Z,MEMBER,@isodrosotherm setting `indexpath=''` will suppress the use of the external index file.,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1214654475
https://github.com/pydata/xarray/issues/4118#issuecomment-1042753800,https://api.github.com/repos/pydata/xarray/issues/4118,1042753800,IC_kwDOAMm_X84-JykI,226037,2022-02-17T09:41:29Z,2022-02-17T09:53:55Z,MEMBER,"@kmuehlbauer in the representation I use the fully qualified name for the dimension / coordinate, but the corresponding `DataArray` will use the basename, e.g. both array will have `lat` as a coordinate. Sorry for the confusion, I need to add more context to the README.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,628719058
https://github.com/pydata/xarray/issues/4118#issuecomment-1042656377,https://api.github.com/repos/pydata/xarray/issues/4118,1042656377,IC_kwDOAMm_X84-Jax5,226037,2022-02-17T07:39:15Z,2022-02-17T08:17:51Z,MEMBER,"@TomNicholas (cc @mraspaud)

> Do you have use cases which one of these designs could handle but the other couldn't?

The two main classes of on-disk formats that, I know of, which cannot be always represented in the ""group is a Dataset"" approach are:
- in [netCDF following the CF conventions for groups](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html#groups), it is legal for an array to refer to a dimension or a coordinate in a different group and so arrays in the same group may have dimensions with the same name, but different size / coordinate values, (this was the orginal motivation to explore the DataGroup approach)
- the current spec for the [Next-generation file formats (NGFF)](https://ngff.openmicroscopy.org) for bio-imaging has all scales of the same 5D data in the same group. (cc @joshmoore)

I don't have an example at hand, but my impression is that satellite products that use HDF5 file format also place arrays with inconsistent dimensions / coordinates in the same group.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,628719058
https://github.com/pydata/xarray/issues/4118#issuecomment-1042664227,https://api.github.com/repos/pydata/xarray/issues/4118,1042664227,IC_kwDOAMm_X84-Jcsj,226037,2022-02-17T07:52:17Z,2022-02-17T07:53:13Z,MEMBER,"@TomNicholas I also have a few comments on the comparison:

> * **Option (1) - Each group is a Dataset**
>   
>   * Model maps more directly onto netCDF (though still not exactly, because netCDF has dimensions as separate objects)

This is only true for flat netCDF files, once you introduce groups in a netCDF AND accept CF conventions the DataGroup approach can map 100% of the files, while the DataTree approach fails on a (admittedly small) class of them.

>   * Enforcing consistency between variables guarantees certain operations are always well-defined (in particular selection via an integer index like in `.isel`).
>   * Guarantees that all valid operations on a Dataset are also valid operations on a single group of a DataTree - so API can be essentially identical to Dataset.

Both points are only true for the DataArray in a single group, once you broadcast any operation to subgroups the two implementations would share the same limitations (dimensions in subgroups can be inconsistent in both cases).

In my opinion the advantage for the DataTree is minimal.

>   * Metadata (i.e. `.attrs`) are arguably most useful when set at this level

The two approach are identical in this respect, group attributes are mapped in the same way to DataTree and DataGroup

I share your views on all other points.","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,628719058
https://github.com/pydata/xarray/issues/1982#issuecomment-1001687725,https://api.github.com/repos/pydata/xarray/issues/1982,1001687725,IC_kwDOAMm_X847tIqt,226037,2021-12-27T18:18:44Z,2021-12-27T18:19:22Z,MEMBER,"Note that current `CF-1.9` now specifies how to read coordinates from any group in file (see [spec](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html#groups)).

If it is not already one of the goals of the new DataTree structure #4665 it would probably best be added. cc @TomNicholas @aurghs ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,304314787
https://github.com/pydata/xarray/issues/5954#issuecomment-964318162,https://api.github.com/repos/pydata/xarray/issues/5954,964318162,IC_kwDOAMm_X845elPS,226037,2021-11-09T16:28:59Z,2021-11-09T16:28:59Z,MEMBER,"> > 2. but most backends serialise writes anyway, so the advantage is limited.
> 
> I'm not sure I understand this comment, specifically what is meant by ""serialise writes"". I often use Xarray to do distributed writes to Zarr stores using 100+ distributed dask workers. It works great. We would need the same thing from a TileDB backend.

I should have added ""except Zarr"" 😅 .

All netCDF writers use `xr.backends.locks.get_write_lock` to get a scheduler appropriate writing lock. The code is intricate and I don't find where to point you, but as I recall the lock was used so only one worker/process/thread could write to disk at a time.

Concurrent writes a la Zarr are awesome and *xarray* supports them now, so my point was: we can add non-concurrent write support to the plugin architecture quite easily and that will serve a lot of users. But supporting Zarr and other advanced backends via the plugin architecture is a lot more work.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1047608434
https://github.com/pydata/xarray/issues/5954#issuecomment-963895846,https://api.github.com/repos/pydata/xarray/issues/5954,963895846,IC_kwDOAMm_X845c-Im,226037,2021-11-09T07:53:00Z,2021-11-09T08:02:20Z,MEMBER,"@rabernat and all, at the time of the read-only backend refactor @aurghs and I spent quite some time analysing write support and thinking of a unifying strategy. This is my interpretation of our findings:

1. one of the big advantages of the unified `xr.open_dataset` API is that you don't need to specify the `engine` of the input data and you can rely on *xarray* guessing it. This is in general non true when you write your data, as you care about what format you are storing it.

2. another advantage of `xr.open_dataset` is that *xarray* manages all the functionaries related to *dask* and to in-memory cacheing, so backends only need to know how to lazily read from the storage. Current (rather complex) implementation has support for writing from *dask* and *distributed* workers but most backends serialise writes anyway, so the advantage is limited. This is not to say that it is not worth, but the cost / benefit ratio of supporting potentially distributed writes is much lower than read support.

3. that said, I'd really welcome a unified write API like `ds.save(engine=...)` or even `xr.save_dataset(ds, engine=...)` with a `engine` keyword argument and possibly other common options. Adding support for a single `save_dataset` entry point to the backend API is trivial, but adding full support for possibly distributed writes looks like it is much more work.

Also note that ATM @aurghs and I are overloaded at work and we would have very little time that we can spend on this :/","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1047608434
https://github.com/pydata/xarray/pull/5351#issuecomment-845842353,https://api.github.com/repos/pydata/xarray/issues/5351,845842353,MDEyOklzc3VlQ29tbWVudDg0NTg0MjM1Mw==,226037,2021-05-21T10:09:43Z,2021-05-21T10:10:27Z,MEMBER,"@shoyer I have two suggestions:

1. I would very much prefer to have the exception in the top level module in order to allow:
```python
import xarray as xr
try:
    ds = xr.open_dataset(...)
except xr.NoMatchingEngineError:
    ... 
```

2. I feel that the error message is very clear, but the name of the exception seems slightly confusing as it appears to imply that no engine can open the dataset when it is only that we couldn't autodetect which engine to use just inspecting at the `filename_or_obj`. I would prefer something along the lines of `EngineAutodetectionError`. But I don't feel too strong about it.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,895983112
https://github.com/pydata/xarray/issues/5329#issuecomment-843824599,https://api.github.com/repos/pydata/xarray/issues/5329,843824599,MDEyOklzc3VlQ29tbWVudDg0MzgyNDU5OQ==,226037,2021-05-19T07:28:03Z,2021-05-19T07:28:03Z,MEMBER,"@shoyer and @pont-us my take is that `engine=None` is mostly and feature to help new users experiment with xarray. The logic for autodetecting the engine has always been extremely fragile and the result depends on what packages are installed on the system.

I think it is OK to add a dedicated `xarray.EngineGuessingError`, but I'd not try anything more complex and in general invite users to pass `engine` explicitly.

Examples of strings that identify a dataset when the right backend is installed, but are not paths and the `FileNotFoundError ` would sound confusing:
- `/vsizip/my.zip/my.tif` with `rioxarray`
- `https://myhost/myfile.nc` with `netcdf4` and others","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,894125618
https://github.com/pydata/xarray/issues/5232#issuecomment-833792726,https://api.github.com/repos/pydata/xarray/issues/5232,833792726,MDEyOklzc3VlQ29tbWVudDgzMzc5MjcyNg==,226037,2021-05-06T19:14:44Z,2021-05-06T19:14:44Z,MEMBER,@TomNicholas feel free to close the issue once you are done.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833791756,https://api.github.com/repos/pydata/xarray/issues/5232,833791756,MDEyOklzc3VlQ29tbWVudDgzMzc5MTc1Ng==,226037,2021-05-06T19:13:20Z,2021-05-06T19:13:20Z,MEMBER,"`12899 passed, 1145 skipped, 211 xfailed, 63 xpassed, 321 warnings` on my Mac.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833781911,https://api.github.com/repos/pydata/xarray/issues/5232,833781911,MDEyOklzc3VlQ29tbWVudDgzMzc4MTkxMQ==,226037,2021-05-06T18:58:28Z,2021-05-06T18:58:28Z,MEMBER,"> How many xarray devs does it take to do a release? Answer: at least 5 apparently

🤦 

But next time it will be sooooooo smooth!","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833779947,https://api.github.com/repos/pydata/xarray/issues/5232,833779947,MDEyOklzc3VlQ29tbWVudDgzMzc3OTk0Nw==,226037,2021-05-06T18:55:33Z,2021-05-06T18:55:33Z,MEMBER,I'm testing after `pip install -U xarray` just to be on the safe side 😄 ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833773183,https://api.github.com/repos/pydata/xarray/issues/5232,833773183,MDEyOklzc3VlQ29tbWVudDgzMzc3MzE4Mw==,226037,2021-05-06T18:49:12Z,2021-05-06T18:49:12Z,MEMBER,"> hmm should I also delete the tag? It appears to be also linked to one of @keewis ' PRs (#5272)

yes, sorry: delete release AND tag. Then re-create release.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833765097,https://api.github.com/repos/pydata/xarray/issues/5232,833765097,MDEyOklzc3VlQ29tbWVudDgzMzc2NTA5Nw==,226037,2021-05-06T18:37:18Z,2021-05-06T18:37:18Z,MEMBER,Deleting and re-creating the release should work (I've done it on one of my projects),"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833751992,https://api.github.com/repos/pydata/xarray/issues/5232,833751992,MDEyOklzc3VlQ29tbWVudDgzMzc1MTk5Mg==,226037,2021-05-06T18:17:47Z,2021-05-06T18:17:47Z,MEMBER,"> I guess I can't do this because I'm no one of the registered package owners on PyPI?

Nope. The maintainers on PyPI are Deepak, Joe, Max and Stephan.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833748655,https://api.github.com/repos/pydata/xarray/issues/5232,833748655,MDEyOklzc3VlQ29tbWVudDgzMzc0ODY1NQ==,226037,2021-05-06T18:12:40Z,2021-05-06T18:13:23Z,MEMBER,@dcherian I'm back. I think the easiest is for you to upload the artefacts using with twine. If you need any help I'm in the zoom room.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833652183,https://api.github.com/repos/pydata/xarray/issues/5232,833652183,MDEyOklzc3VlQ29tbWVudDgzMzY1MjE4Mw==,226037,2021-05-06T16:15:06Z,2021-05-06T16:15:06Z,MEMBER,"@dcherian I'm sorry, I have cannot make it by 12:30 EST. I think you and @TomNicholas can go on without me or I will be back later.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833603212,https://api.github.com/repos/pydata/xarray/issues/5232,833603212,MDEyOklzc3VlQ29tbWVudDgzMzYwMzIxMg==,226037,2021-05-06T15:13:13Z,2021-05-06T16:13:50Z,MEMBER,"@dcherian 11:30-12:30 EST I'm meeting with Stephan and Joe, I hope to have them merge #5235 :)

~12:30 EST is fine by me.~ I cannot make it :/","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833564314,https://api.github.com/repos/pydata/xarray/issues/5232,833564314,MDEyOklzc3VlQ29tbWVudDgzMzU2NDMxNA==,226037,2021-05-06T14:22:55Z,2021-05-06T14:25:12Z,MEMBER,"@TomNicholas I'm in Europe, with a meeting at 17:30-18:30 CEST (11:30-12:30 EST) we can probably start now-ish and finish after 3pm EST. I propose to hijack the community meeting zoom :)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5232#issuecomment-833539672,https://api.github.com/repos/pydata/xarray/issues/5232,833539672,MDEyOklzc3VlQ29tbWVudDgzMzUzOTY3Mg==,226037,2021-05-06T13:50:28Z,2021-05-06T13:50:28Z,MEMBER,"@TomNicholas & @dcherian I'm having a look at the what's new, shall we set a time for going through the release process? do we want do the steps while in a call?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/pull/5244#issuecomment-833537209,https://api.github.com/repos/pydata/xarray/issues/5244,833537209,MDEyOklzc3VlQ29tbWVudDgzMzUzNzIwOQ==,226037,2021-05-06T13:47:39Z,2021-05-06T13:48:37Z,MEMBER,Any consensus on whether this is ready to merge? We should start the release process shortly (once the US wakes up).,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,873842812
https://github.com/pydata/xarray/issues/5232#issuecomment-832448319,https://api.github.com/repos/pydata/xarray/issues/5232,832448319,MDEyOklzc3VlQ29tbWVudDgzMjQ0ODMxOQ==,226037,2021-05-05T06:35:02Z,2021-05-05T10:38:35Z,MEMBER,"Form what I can see the #5258 ""bump versions"" looks ready, someone with knowledge about minimum versions please merge it.

After that is in, @dcherian you can probably uncomment the `var._meta` bit in #4740 ""faster interp"" and we can merge it as well. Again I'm not a user of that part of code, and I would feel more conformable if someone with more knowledge would click on the ""merge"" button.

This leaves only #5235 as a blocker that has a failing test, a proposed fix by @keewis. ~but the OP hasn't responded yet. How should we handle it?~ This looks ready to merge now. Sorry @tomwhite I read the timestamps wrong. Great job!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/pull/5244#issuecomment-832574270,https://api.github.com/repos/pydata/xarray/issues/5244,832574270,MDEyOklzc3VlQ29tbWVudDgzMjU3NDI3MA==,226037,2021-05-05T10:13:15Z,2021-05-05T10:13:15Z,MEMBER,"@andersy005 are you OK to try and merge this ""as is"" sometime today and then help us making a couple of tests on `test.pypi.prg` before doing the real release tomorrow?

(worst case: we release the old way)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,873842812
https://github.com/pydata/xarray/issues/5232#issuecomment-832452876,https://api.github.com/repos/pydata/xarray/issues/5232,832452876,MDEyOklzc3VlQ29tbWVudDgzMjQ1Mjg3Ng==,226037,2021-05-05T06:44:59Z,2021-05-05T06:46:36Z,MEMBER,"Any thoughts on merging #5244 and doing the v0.18.0 release via GitHub Actions?

I'm using GA in a couple of repositories and I find them very handy, but I usually had to make a couple of releases before getting all the details right, which looks awkward to do with a high profile project like *xarray*.

We could try release one or more release candidates and go for `v0.18.0` only after we are sure the GA release procedure is working though.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/pull/5258#issuecomment-832443953,https://api.github.com/repos/pydata/xarray/issues/5258,832443953,MDEyOklzc3VlQ29tbWVudDgzMjQ0Mzk1Mw==,226037,2021-05-05T06:25:18Z,2021-05-05T06:25:18Z,MEMBER,"@dcherian with dask>=2.15 you can update #4740 that looks mergiable as well, right?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,875721501
https://github.com/pydata/xarray/issues/5257#issuecomment-832206684,https://api.github.com/repos/pydata/xarray/issues/5257,832206684,MDEyOklzc3VlQ29tbWVudDgzMjIwNjY4NA==,226037,2021-05-04T20:02:00Z,2021-05-04T20:02:00Z,MEMBER,"I'll close this issue, @chiaral please follow up on ecmwf/cfgrib#231","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,875696070
https://github.com/pydata/xarray/issues/5257#issuecomment-832204036,https://api.github.com/repos/pydata/xarray/issues/5257,832204036,MDEyOklzc3VlQ29tbWVudDgzMjIwNDAzNg==,226037,2021-05-04T19:56:52Z,2021-05-04T19:56:52Z,MEMBER,@chiaral thanks for spotting this issue! This is actually a bug in *cfgrib* 0.9.9.0 not *xarray*. I'll transfer it to the *cfgrib* repo.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,875696070
https://github.com/pydata/xarray/pull/5234#issuecomment-831856905,https://api.github.com/repos/pydata/xarray/issues/5234,831856905,MDEyOklzc3VlQ29tbWVudDgzMTg1NjkwNQ==,226037,2021-05-04T11:02:15Z,2021-05-04T11:02:15Z,MEMBER,"@max-sixty & @andersy005 mine was more of a general comment. It is OK to merge it for me, but please after the release!","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870619014
https://github.com/pydata/xarray/pull/5234#issuecomment-831740472,https://api.github.com/repos/pydata/xarray/issues/5234,831740472,MDEyOklzc3VlQ29tbWVudDgzMTc0MDQ3Mg==,226037,2021-05-04T07:32:32Z,2021-05-04T07:32:32Z,MEMBER,"I feel this PR is too big and diverse to accept it as a whole.

For example I like most changes from older style formatting to f-strings, but I disagree strongly the moving the `return` statements into functions improves readability.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870619014
https://github.com/pydata/xarray/pull/5237#issuecomment-831701789,https://api.github.com/repos/pydata/xarray/issues/5237,831701789,MDEyOklzc3VlQ29tbWVudDgzMTcwMTc4OQ==,226037,2021-05-04T06:01:40Z,2021-05-04T06:01:40Z,MEMBER,"@TomNicholas see my comment here: https://github.com/pydata/xarray/issues/5073#issuecomment-831700309

I think the best course for now is to only raise the deprecation warning in zarr and pydap, as al other in-tree backends actually support the `lock` argument.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,871234354
https://github.com/pydata/xarray/issues/5073#issuecomment-831700309,https://api.github.com/repos/pydata/xarray/issues/5073,831700309,MDEyOklzc3VlQ29tbWVudDgzMTcwMDMwOQ==,226037,2021-05-04T05:57:19Z,2021-05-04T05:57:19Z,MEMBER,"Sorry for being so late to the party! I thought @aurghs did respond to this issue and forgot about it.

What has happened is not that `lock` (and `group` for the matter) disappeared altogether, but it has been moved to be a backend specific keyword argument. As far as I can see most internal backends still support it as before: `cfgrib`, `netcdf4`, `pseudonetcdf`, `pynio` and `scipy`.

The main difference is that `lock` was silently ignored by backend that don't support it like `zarr` and `pydap`.

The solution is to in fact only advertise the deprecation for those backends in my opinion as the functionality is legit for most of the backends.

Sorry again for seeing this so late.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,840258082
https://github.com/pydata/xarray/issues/5232#issuecomment-829923818,https://api.github.com/repos/pydata/xarray/issues/5232,829923818,MDEyOklzc3VlQ29tbWVudDgyOTkyMzgxOA==,226037,2021-04-30T08:10:37Z,2021-04-30T08:10:51Z,MEMBER,"I propose the following timeline that is the fastest I can personally try:

- Monday May the 3rd, feature freeze, please refrain from merging new features unless they are discussed here
- during feature freeze everybody please help reviewing the PR in the list above
- Thursday the 6th, target release day, the best would be to schedule a window for a couple of hours (?) for @TomAugspurger and me to going through the release steps together with @dcherian.

@TomAugspurger and others does it work for you all?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,870292042
https://github.com/pydata/xarray/issues/5138#issuecomment-826344428,https://api.github.com/repos/pydata/xarray/issues/5138,826344428,MDEyOklzc3VlQ29tbWVudDgyNjM0NDQyOA==,226037,2021-04-25T15:41:07Z,2021-04-25T15:41:07Z,MEMBER,"I don't know, I've never managed to get *cfgrib* and *xarray* to install on python 3.9. The *conda* solver fails.

It looks like there is a conflict between *xarray* and *eccodes* dependencies, but I didn't investigate.

","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/pull/5188#issuecomment-822685095,https://api.github.com/repos/pydata/xarray/issues/5188,822685095,MDEyOklzc3VlQ29tbWVudDgyMjY4NTA5NQ==,226037,2021-04-19T18:33:23Z,2021-04-19T18:34:12Z,MEMBER,"> I would do another regex special to check whether it contains a `\`

@max-sixty I was thinking to something more brutal: I would drop the `r`-prefix everywhere and fix by hand the failing tests (if any) ;)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,860909006
https://github.com/pydata/xarray/pull/5188#issuecomment-822677989,https://api.github.com/repos/pydata/xarray/issues/5188,822677989,MDEyOklzc3VlQ29tbWVudDgyMjY3Nzk4OQ==,226037,2021-04-19T18:21:59Z,2021-04-19T18:21:59Z,MEMBER,"@max-sixty I like the cleanup even it it is rather big. I for one find it very confusing when tests use non standard helpers.

BTW, I think you can skip the `r`-prefix everywhere making the change even more appealing. It is only useful when using `\` operands in the the match string which is almost never the case in xarray.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,860909006
https://github.com/pydata/xarray/issues/4697#issuecomment-822646296,https://api.github.com/repos/pydata/xarray/issues/4697,822646296,MDEyOklzc3VlQ29tbWVudDgyMjY0NjI5Ng==,226037,2021-04-19T17:31:38Z,2021-04-19T17:32:11Z,MEMBER,"@max-sixty I'm +1 on deprecating *xarray* flavour of `open_rasterio` and direct users to `rioxarray`.

BTW, I would rather prefer the next release to be `0.18.0` as the backend changes are both large and user visible (`open_dataset` now accept `**kwargs` that are added to `**backend_kwargs`).","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,767941842
https://github.com/pydata/xarray/issues/5175#issuecomment-822377249,https://api.github.com/repos/pydata/xarray/issues/5175,822377249,MDEyOklzc3VlQ29tbWVudDgyMjM3NzI0OQ==,226037,2021-04-19T10:56:01Z,2021-04-19T10:56:01Z,MEMBER,"@kmuehlbauer precisely. For example the `AbstractDataStore` is not part of the API anymore and it is kept only for backward compatibility.

What I see missing is a way defined at API level for the backends to ""attach"" arbitrary information and possibly code to the backend `Dataset`s. cc @shoyer @jhamman ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,860180906
https://github.com/pydata/xarray/issues/5132#issuecomment-820374739,https://api.github.com/repos/pydata/xarray/issues/5132,820374739,MDEyOklzc3VlQ29tbWVudDgyMDM3NDczOQ==,226037,2021-04-15T12:12:26Z,2021-04-15T12:12:26Z,MEMBER,Closed by #5135 ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,853473276
https://github.com/pydata/xarray/pull/5135#issuecomment-820374206,https://api.github.com/repos/pydata/xarray/issues/5135,820374206,MDEyOklzc3VlQ29tbWVudDgyMDM3NDIwNg==,226037,2021-04-15T12:11:26Z,2021-04-15T12:11:26Z,MEMBER,@bcbnz thanks for the help! I'll merge it.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,853644364
https://github.com/pydata/xarray/pull/5135#issuecomment-818804036,https://api.github.com/repos/pydata/xarray/issues/5135,818804036,MDEyOklzc3VlQ29tbWVudDgxODgwNDAzNg==,226037,2021-04-13T14:58:07Z,2021-04-13T14:58:07Z,MEMBER,@aurghs can you confirm that all failures are unrelated to the changes?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,853644364
https://github.com/pydata/xarray/issues/5138#issuecomment-817864442,https://api.github.com/repos/pydata/xarray/issues/5138,817864442,MDEyOklzc3VlQ29tbWVudDgxNzg2NDQ0Mg==,226037,2021-04-12T14:34:13Z,2021-04-12T14:34:13Z,MEMBER,"Yes, I would close the issue.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/issues/5138#issuecomment-817566465,https://api.github.com/repos/pydata/xarray/issues/5138,817566465,MDEyOklzc3VlQ29tbWVudDgxNzU2NjQ2NQ==,226037,2021-04-12T07:37:25Z,2021-04-12T07:37:25Z,MEMBER,"@keewis after merging #5139 the CI should not be failing anymore. The problem is now that *cfgrib* may not be consistently tested on all jobs and failures are silent.

I'll wait a bit for the fix in `python-eccodes`, otherwise I'll do a new release of the conda package of *cfgrib*.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/pull/5139#issuecomment-817560437,https://api.github.com/repos/pydata/xarray/issues/5139,817560437,MDEyOklzc3VlQ29tbWVudDgxNzU2MDQzNw==,226037,2021-04-12T07:28:37Z,2021-04-12T07:28:37Z,MEMBER,I'll merge it now to stop the CI from failing. The real fix is on the `python-eccodes` side: https://github.com/conda-forge/python-eccodes-feedstock/issues/69 and https://github.com/conda-forge/python-eccodes-feedstock/issues/71,"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855388231
https://github.com/pydata/xarray/issues/5138#issuecomment-817557923,https://api.github.com/repos/pydata/xarray/issues/5138,817557923,MDEyOklzc3VlQ29tbWVudDgxNzU1NzkyMw==,226037,2021-04-12T07:25:03Z,2021-04-12T07:25:03Z,MEMBER,"Technically this is an incompatibility between `python-eccodes` and `eccodes`, I'm trying to resolve it via a PR to the `python-eccodes-feedstock`: https://github.com/conda-forge/python-eccodes-feedstock/pull/71","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/issues/5138#issuecomment-817358999,https://api.github.com/repos/pydata/xarray/issues/5138,817358999,MDEyOklzc3VlQ29tbWVudDgxNzM1ODk5OQ==,226037,2021-04-11T19:23:14Z,2021-04-11T19:28:45Z,MEMBER,"As a general measure I would add `ImportError` to the exception caught on import so we avoid to crash *xarray*:

https://github.com/pydata/xarray/blob/186c2ff6542f090a8e97ffb755f866030be30be9/xarray/backends/cfgrib_.py#L18-L29

To work around the current problem we may need to add a `eccodes>=2.21.0` to the CI :/","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/issues/5138#issuecomment-817357498,https://api.github.com/repos/pydata/xarray/issues/5138,817357498,MDEyOklzc3VlQ29tbWVudDgxNzM1NzQ5OA==,226037,2021-04-11T19:12:13Z,2021-04-11T19:12:30Z,MEMBER,"Thanks @keewis! ATM the main suspect is a flaky the dependency between `python-eccodes` and `eccodes`, not `cfgrib` itself. So it may look like a random error in CI.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/issues/5138#issuecomment-817355970,https://api.github.com/repos/pydata/xarray/issues/5138,817355970,MDEyOklzc3VlQ29tbWVudDgxNzM1NTk3MA==,226037,2021-04-11T19:00:30Z,2021-04-11T19:00:30Z,MEMBER,Looking into ecmwf/cfgrib#226 that seems related.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,855330062
https://github.com/pydata/xarray/issues/5125#issuecomment-817354982,https://api.github.com/repos/pydata/xarray/issues/5125,817354982,MDEyOklzc3VlQ29tbWVudDgxNzM1NDk4Mg==,226037,2021-04-11T18:53:03Z,2021-04-11T18:53:03Z,MEMBER,"This didn't close automatically, but it is closed by #5127 ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,852256995
https://github.com/pydata/xarray/pull/5033#issuecomment-816258482,https://api.github.com/repos/pydata/xarray/issues/5033,816258482,MDEyOklzc3VlQ29tbWVudDgxNjI1ODQ4Mg==,226037,2021-04-08T22:01:50Z,2021-04-08T22:07:27Z,MEMBER,"> Making a backend doesn't have to be super difficult either depending if you already have a nice 3rd party module you can thinly wrap to return a Dataset instead of whatever is the default

Absolutely agree: https://github.com/corteva/rioxarray/blob/master/rioxarray/xarray_plugin.py

(the PR took a grand total of 48 hours from open to merge: https://github.com/corteva/rioxarray/pull/281)

> It's funny how different our backgrounds are, I don't think I've had to deal with `console_script`s.

```
$ grep -r console_scripts develop/ | wc -l
      23
```

😅 ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,831008649
https://github.com/pydata/xarray/pull/5033#issuecomment-816173649,https://api.github.com/repos/pydata/xarray/issues/5033,816173649,MDEyOklzc3VlQ29tbWVudDgxNjE3MzY0OQ==,226037,2021-04-08T20:41:29Z,2021-04-08T20:41:29Z,MEMBER,"> > The first comment is that I see the point of the feature at a theoretical level, but I'm at the third external backend that I'm writing and I didn't miss it. Adding an entrypoint is very easy and works seamlessly during development.
> > Do you have in mind any use case where this is more convenient than adding an entrypoint?
> 
> I simply want to do:
> 
> ```python
> from custom_backend import engine
> 
> ds = xr.load_dataset(filename, engine=engine)
> ```
> 
> That is much simpler than having to figure out what the **How to register a backend** is talking about. Because I'm a user who doesn't have any grand dreams (yet?) of creating public backend modules I therefore don't see the point in having to do all this extra paperwork.

Well, based on the amount of complexity a developer needs to master in order to write the backend, I would consider the registration to be a relatively trivial bit, especially because the syntax is the same as for the well known `console_script`.

On one hand I judge the feature to be relatively simple to support in the long long term, on the other hand I still feel that its benefit will be be quite marginal. Therefore I'm still a mild -1.

> > ... we ask backend developers to inherit from `BackendEntrypoint`, for the sake of consistency I would enforce it here as well, instead to use duck-typing.
> 
> That's not how I read the docs. If this is how we actually want it then some words in it should be replaced with ""must"" and ""requires"".
> 
> But I don't think that should be such a hard requirement when a user insists on using a custom engine this way. I see it as an advanced option where it's the users responsibility to make sure that the `engine` class has
> 
> * the open_dataset method
> * the open_dataset_parameters attribute
> * the guess_can_open method
> 
> Which is very simple to do, see the test for an example. Subclassing using `BackendEntrypoint` adds complexity and readability issues so I want to at least feel a little motivated to use it but there's nothing fancy going on there, is there any plans?

On this one I can side with you. The initial proposal from @aurghs and myself was to use a `dict` 😄 .

This one is a higher lever design decisione, I think @jhamman and @shoyer need to weight in.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,831008649
https://github.com/pydata/xarray/pull/5136#issuecomment-816037214,https://api.github.com/repos/pydata/xarray/issues/5136,816037214,MDEyOklzc3VlQ29tbWVudDgxNjAzNzIxNA==,226037,2021-04-08T18:18:40Z,2021-04-08T18:18:40Z,MEMBER,This VERY important to merge!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,853705865
https://github.com/pydata/xarray/pull/5135#issuecomment-816027472,https://api.github.com/repos/pydata/xarray/issues/5135,816027472,MDEyOklzc3VlQ29tbWVudDgxNjAyNzQ3Mg==,226037,2021-04-08T18:03:14Z,2021-04-08T18:03:14Z,MEMBER,"@aurghs you may also use `_normalize_path` that does all the checks:

https://github.com/pydata/xarray/blob/master/xarray/backends/api.py#L112","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,853644364
https://github.com/pydata/xarray/pull/5135#issuecomment-816019678,https://api.github.com/repos/pydata/xarray/issues/5135,816019678,MDEyOklzc3VlQ29tbWVudDgxNjAxOTY3OA==,226037,2021-04-08T17:50:25Z,2021-04-08T17:54:36Z,MEMBER,"@aurghs & @dcherian note that at the moment most backends accept `pathlib.Path` (but it is not tested), so the `isintance(..., str)` doesn't run `expanduser` in that case.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,853644364
https://github.com/pydata/xarray/pull/5033#issuecomment-815841228,https://api.github.com/repos/pydata/xarray/issues/5033,815841228,MDEyOklzc3VlQ29tbWVudDgxNTg0MTIyOA==,226037,2021-04-08T13:49:55Z,2021-04-08T13:49:55Z,MEMBER,"@Illviljan sorry for being late to the party.

The first comment is that I see the point of the feature at a theoretical level, but I'm at the third external backend that I'm writing and I didn't miss it. Adding an entrypoint is very easy and works seamlessly during development.

Do you have in mind any use case where this is more convenient than adding an entrypoint?

WRT the implementation, at the request of @shoyer and @jhamman, we ask backend developers to inherit from `BackendEntrypoint`, for the sake of consistency I would enforce it here as well, instead to use duck-typing.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,831008649
https://github.com/pydata/xarray/issues/5125#issuecomment-814818272,https://api.github.com/repos/pydata/xarray/issues/5125,814818272,MDEyOklzc3VlQ29tbWVudDgxNDgxODI3Mg==,226037,2021-04-07T11:00:06Z,2021-04-07T11:00:06Z,MEMBER,Same with `BackendArray` for plugin that want to support lazy loading.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,852256995
https://github.com/pydata/xarray/issues/4142#issuecomment-814074112,https://api.github.com/repos/pydata/xarray/issues/4142,814074112,MDEyOklzc3VlQ29tbWVudDgxNDA3NDExMg==,226037,2021-04-06T12:18:43Z,2021-04-06T12:18:43Z,MEMBER,I started a PR against *rioxarray* to add an engine via the plugin interface see https://github.com/corteva/rioxarray/pull/281,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,636493109
https://github.com/pydata/xarray/pull/5112#issuecomment-813942168,https://api.github.com/repos/pydata/xarray/issues/5112,813942168,MDEyOklzc3VlQ29tbWVudDgxMzk0MjE2OA==,226037,2021-04-06T08:39:19Z,2021-04-06T09:18:06Z,MEMBER,If nobody objects I'll merge this shortly as this breaks building against `master` of external projects testing out the backend-plugin infrastructure. We can always add a deprecation warning on a follow-up PR.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,850236909
https://github.com/pydata/xarray/pull/5112#issuecomment-813355119,https://api.github.com/repos/pydata/xarray/issues/5112,813355119,MDEyOklzc3VlQ29tbWVudDgxMzM1NTExOQ==,226037,2021-04-05T11:47:49Z,2021-04-05T11:47:49Z,MEMBER,"I see quite a few uses ""in the wild"":

https://github.com/search?l=Python&q=LazilyOuterIndexedArray&type=Code

I would suggest to keep it long term to avoid migration pains to external backend developers.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,850236909
https://github.com/pydata/xarray/issues/5098#issuecomment-812453263,https://api.github.com/repos/pydata/xarray/issues/5098,812453263,MDEyOklzc3VlQ29tbWVudDgxMjQ1MzI2Mw==,226037,2021-04-02T09:33:24Z,2021-04-02T09:33:43Z,MEMBER,"The reason to delegate all path normalisation to backends is that not all strings are paths, for example `'NETCDF:""~/sst.nc"":tos'` is a valid source string for GDAL / rasterio.

I would suggest to add path normalisation to the backends that needs them, in order to avoid any special case in the common code path.

@aurghs I suggest you add `os.path.expanduser` in the netCDF backend.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,847014702
https://github.com/pydata/xarray/pull/5083#issuecomment-809688189,https://api.github.com/repos/pydata/xarray/issues/5083,809688189,MDEyOklzc3VlQ29tbWVudDgwOTY4ODE4OQ==,226037,2021-03-29T20:26:02Z,2021-03-29T20:57:17Z,MEMBER,"@keewis @mathause and @b8raoult the change looks good to me.

Non-conda users may very well hit the `RuntimeError` and xarray should not fail to load in that case, but throwing a the warning looks sensible to me.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,842535132
https://github.com/pydata/xarray/issues/4803#issuecomment-793071999,https://api.github.com/repos/pydata/xarray/issues/4803,793071999,MDEyOklzc3VlQ29tbWVudDc5MzA3MTk5OQ==,226037,2021-03-08T20:58:02Z,2021-03-08T20:58:02Z,MEMBER,Closed by #4810 ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,785233324
https://github.com/pydata/xarray/pull/4989#issuecomment-791408222,https://api.github.com/repos/pydata/xarray/issues/4989,791408222,MDEyOklzc3VlQ29tbWVudDc5MTQwODIyMg==,226037,2021-03-05T13:06:43Z,2021-03-05T13:06:53Z,MEMBER,The PR is ready for review. All tests pass. I plan to write the what's new over the week end and target a merge on Monday.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,821312099
https://github.com/pydata/xarray/issues/4987#issuecomment-790782639,https://api.github.com/repos/pydata/xarray/issues/4987,790782639,MDEyOklzc3VlQ29tbWVudDc5MDc4MjYzOQ==,226037,2021-03-04T17:16:48Z,2021-03-04T17:22:31Z,MEMBER,"@jp-dark it is in fact possible to write an _xarray_ backend without explicitly depending on _xarray_ in your `setup.py` if you put all your backend glue code in a separate module not imported by the main `__init__.py`.

We use the setuptools entrypoints infrastructure that triggers a module load only from within _xarray_ itself.

This is still work in progress, but we are implementing this strategy in _cfgrib_ with success. You can get inspiration from the following PR by @aurghs:

https://github.com/ecmwf/cfgrib/pull/203
","{""total_count"": 2, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 2, ""rocket"": 0, ""eyes"": 0}",,820480606
https://github.com/pydata/xarray/issues/4894#issuecomment-780731411,https://api.github.com/repos/pydata/xarray/issues/4894,780731411,MDEyOklzc3VlQ29tbWVudDc4MDczMTQxMQ==,226037,2021-02-17T17:46:46Z,2021-02-17T17:46:46Z,MEMBER,I don't think we will be ready by this week-end and we don't want to rush the switch to the new API without some thorough testing by others. We will wait for the next release.,"{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,806436724
https://github.com/pydata/xarray/issues/4253#issuecomment-780682558,https://api.github.com/repos/pydata/xarray/issues/4253,780682558,MDEyOklzc3VlQ29tbWVudDc4MDY4MjU1OA==,226037,2021-02-17T16:33:31Z,2021-02-17T16:33:31Z,MEMBER,"@jhamman & @shoyer, unfortunately neither @aurghs nor myself will be available tomorrow, 18 Feb. We can skip this week's meeting or reschedule it, same time but another day. Your call.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,663968779
https://github.com/pydata/xarray/issues/4894#issuecomment-778060647,https://api.github.com/repos/pydata/xarray/issues/4894,778060647,MDEyOklzc3VlQ29tbWVudDc3ODA2MDY0Nw==,226037,2021-02-12T08:44:55Z,2021-02-12T08:45:23Z,MEMBER,"The new flexible backend API is almost ready #4309 (see PRs with label [`CZI Grant`](https://github.com/pydata/xarray/pulls?q=label%3A%22CZI+Grant%22)) and the plan is for it to become the default backend API for the next major release (cc @shoyer @jhamman)

I'll prepare the PR to move the code in `apiv2.py` to `api.py` soon.

@dcherian do you have a target release date?","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,806436724
https://github.com/pydata/xarray/pull/4823#issuecomment-764610726,https://api.github.com/repos/pydata/xarray/issues/4823,764610726,MDEyOklzc3VlQ29tbWVudDc2NDYxMDcyNg==,226037,2021-01-21T12:29:32Z,2021-01-21T12:29:32Z,MEMBER,@martindurant with respect to the backend API (old and new) looks good to me. I'm don't know `fsspec` so I can't comment on that.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,788398518
https://github.com/pydata/xarray/pull/4823#issuecomment-764605415,https://api.github.com/repos/pydata/xarray/issues/4823,764605415,MDEyOklzc3VlQ29tbWVudDc2NDYwNTQxNQ==,226037,2021-01-21T12:19:24Z,2021-01-21T12:19:24Z,MEMBER,@martindurant it is OK to let every backend raise errors for unsupported input. So no need to add any additional logic here IMO.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,788398518
https://github.com/pydata/xarray/pull/4811#issuecomment-762741103,https://api.github.com/repos/pydata/xarray/issues/4811,762741103,MDEyOklzc3VlQ29tbWVudDc2Mjc0MTEwMw==,226037,2021-01-19T10:09:54Z,2021-01-19T10:10:20Z,MEMBER,"With this change `xr.list_engines()` returns a dictionary with all usable engines.

The implementation is forward compatible, so once backends are split off the main package newer backend registered via the APIv2 plugin interface have precedence.

I'll merge it.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,786107421
https://github.com/pydata/xarray/pull/4809#issuecomment-761124713,https://api.github.com/repos/pydata/xarray/issues/4809,761124713,MDEyOklzc3VlQ29tbWVudDc2MTEyNDcxMw==,226037,2021-01-15T19:00:56Z,2021-01-15T19:00:56Z,MEMBER,"woops, I see you didn't finish, yet :)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,785997226
https://github.com/pydata/xarray/pull/4809#issuecomment-761123911,https://api.github.com/repos/pydata/xarray/issues/4809,761123911,MDEyOklzc3VlQ29tbWVudDc2MTEyMzkxMQ==,226037,2021-01-15T18:59:29Z,2021-01-15T18:59:29Z,MEMBER,I'll merge it after the last cleanup as I need this to start working on the API v1 to v2 PR. Thanks @shoyer !,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,785997226
https://github.com/pydata/xarray/pull/4811#issuecomment-760329796,https://api.github.com/repos/pydata/xarray/issues/4811,760329796,MDEyOklzc3VlQ29tbWVudDc2MDMyOTc5Ng==,226037,2021-01-14T17:03:37Z,2021-01-14T17:03:37Z,MEMBER,"Using `importlib.util.find_spec ` is very elegant but much less readable than a `try: except ModuleNotFoundError:` block, I suggest to convert all checks on imports to them.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,786107421
https://github.com/pydata/xarray/issues/4524#issuecomment-753607645,https://api.github.com/repos/pydata/xarray/issues/4524,753607645,MDEyOklzc3VlQ29tbWVudDc1MzYwNzY0NQ==,226037,2021-01-03T12:10:31Z,2021-01-03T12:10:31Z,MEMBER,"@mathause I think you are right, #4733 (the issue that #4737 aimed to fix) is probably not related to *cfgrib*, I didn't notice that no backend code was mentioned in the traceback.

I was fooled by the fact that we had a know bug in *cfgrib* https://github.com/ecmwf/cfgrib/issues/157 and the error message reported in #4733 was the same.

So the PR #4737 is needed anyhow, but it doesn't really solve the issue it refers to :/","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,724777139
https://github.com/pydata/xarray/issues/4733#issuecomment-751682827,https://api.github.com/repos/pydata/xarray/issues/4733,751682827,MDEyOklzc3VlQ29tbWVudDc1MTY4MjgyNw==,226037,2020-12-28T11:34:22Z,2020-12-28T11:34:22Z,MEMBER,"Looks like an effective way to fix the bug is in xarray itself, so I reopen the issue.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,774553196
https://github.com/pydata/xarray/issues/4733#issuecomment-751232371,https://api.github.com/repos/pydata/xarray/issues/4733,751232371,MDEyOklzc3VlQ29tbWVudDc1MTIzMjM3MQ==,226037,2020-12-25T10:58:58Z,2020-12-25T10:58:58Z,MEMBER,"@DanielAdriaansen thanks for reporting, this is a duplicate of https://github.com/ecmwf/cfgrib/issues/157 so I'm going to close this one, and you can follow there.

I'm a bit embarrassed as @aurghs identified this bug a while back, but I forgot about it!

The fix should be easy, I'll try to make a release shortly.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,774553196
https://github.com/pydata/xarray/pull/4724#issuecomment-750922630,https://api.github.com/repos/pydata/xarray/issues/4724,750922630,MDEyOklzc3VlQ29tbWVudDc1MDkyMjYzMA==,226037,2020-12-24T16:29:31Z,2020-12-24T16:29:31Z,MEMBER,I merge it as it involves only the new APIv2 code.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,773481918
https://github.com/pydata/xarray/pull/4725#issuecomment-750921848,https://api.github.com/repos/pydata/xarray/issues/4725,750921848,MDEyOklzc3VlQ29tbWVudDc1MDkyMTg0OA==,226037,2020-12-24T16:25:19Z,2020-12-24T16:25:19Z,MEMBER,I merge as it has been discussed yesterday in the community meeting.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,773497334
https://github.com/pydata/xarray/pull/4725#issuecomment-750288021,https://api.github.com/repos/pydata/xarray/issues/4725,750288021,MDEyOklzc3VlQ29tbWVudDc1MDI4ODAyMQ==,226037,2020-12-23T12:51:52Z,2020-12-23T12:51:52Z,MEMBER,"@aurghs I think you should check what documentation needs updating beside the doctring.

Also this deserves and entry in what's new.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,773497334
https://github.com/pydata/xarray/pull/4725#issuecomment-749977773,https://api.github.com/repos/pydata/xarray/issues/4725,749977773,MDEyOklzc3VlQ29tbWVudDc0OTk3Nzc3Mw==,226037,2020-12-23T07:07:07Z,2020-12-23T07:07:26Z,MEMBER,"@aurghs there's a conflict, would you please fix it?","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,773497334
https://github.com/pydata/xarray/pull/4701#issuecomment-748001346,https://api.github.com/repos/pydata/xarray/issues/4701,748001346,MDEyOklzc3VlQ29tbWVudDc0ODAwMTM0Ng==,226037,2020-12-18T10:10:32Z,2020-12-18T10:10:32Z,MEMBER,"@max-sixty there's no direct test for the backend Store classes, only indirect tests through `open_dataset`. For example all other beckends do support `pathlib.Path` but none is tested.

Once we remove `_normalize_path` (PR is coming, and we may need a bit of discussion before approval) we will be able to test all backends.

I propose to merge this PR as it is.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,769288855
https://github.com/pydata/xarray/issues/4309#issuecomment-747055666,https://api.github.com/repos/pydata/xarray/issues/4309,747055666,MDEyOklzc3VlQ29tbWVudDc0NzA1NTY2Ng==,226037,2020-12-16T21:35:57Z,2020-12-16T21:35:57Z,MEMBER,"I'm looking at other bits of knowledge of how backends work that are still present in the generic parts of `open_dataset`.

We see `_autodetect_engine` and `_normalize_path`.

We aim at removing `_autodetect_engine` in favour of adding a new `can_open(filename_or_obj, ...)` backend function declared via the plugin interface.

On the other hand `_normalize_path` can be removed entirely once `ZarrStore.open_group` will accept `os.PathLike` objects.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,672912921
https://github.com/pydata/xarray/pull/4577#issuecomment-742413228,https://api.github.com/repos/pydata/xarray/issues/4577,742413228,MDEyOklzc3VlQ29tbWVudDc0MjQxMzIyOA==,226037,2020-12-10T09:55:55Z,2020-12-10T09:55:55Z,MEMBER,"@keewis WRT your comments on list comprehensions we at B-Open prefer to use them only when they make the code one line and actually prefer explicit loops otherwise.

This is both because we find them more readable as code and because tracebacks as well are easier to parse when they point to the statement that raised.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,741714847
https://github.com/pydata/xarray/pull/4642#issuecomment-737224309,https://api.github.com/repos/pydata/xarray/issues/4642,737224309,MDEyOklzc3VlQ29tbWVudDczNzIyNDMwOQ==,226037,2020-12-02T13:17:19Z,2020-12-02T13:17:19Z,MEMBER,"These are cosmetic changes to only the `apiv2.py` file and the `Linux py38-backend-api-v2` pass, so I can merge them without much risk.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,755163626
https://github.com/pydata/xarray/pull/4547#issuecomment-723115945,https://api.github.com/repos/pydata/xarray/issues/4547,723115945,MDEyOklzc3VlQ29tbWVudDcyMzExNTk0NQ==,226037,2020-11-06T14:41:32Z,2020-11-06T14:41:32Z,MEMBER,"I fixed the type ints and the two test failures are unrelated to the changes.

I'm going to test my shiny new merge rights :)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,731226031
https://github.com/pydata/xarray/issues/4490#issuecomment-705594621,https://api.github.com/repos/pydata/xarray/issues/4490,705594621,MDEyOklzc3VlQ29tbWVudDcwNTU5NDYyMQ==,226037,2020-10-08T14:06:35Z,2020-10-08T14:06:35Z,MEMBER,"@shoyer I favour option 2. as a stable solution, possibly with all arguments moved to keyword-only ones:
* users don't need to import and additional class
* users get the argument completion on`open_dataset`
* *xarray* does validation and mangling in the class and passes to the backends only the non default values

I'm for using the words decode/decoding but I'm against the use of CF.

What backend will do is map the on-disk representation of the data (typically optimised for space) to the in-memory representation preferred by *xarray* (typically optimised of easy of use). This mapping is especially tricky for time-like variables.

CF is one possible way to specify the map, but it is not the only one. Both the GRIB format and all the spatial formats supported by *GDAL/rasterio* can encode rich data and decoding has (typically) nothing to do with the CF conventions.

My preferred meaning for the `decode_`-options is:
* `True`: the backend attempts to map the data to the *xarray* natural data types (`np.datetime64`, `np.float` with mask and scale)
* `False`: the backend attempts to return a representation of the data as close as possible to the on-disk one

Typically when a user asks the backend not to decode they intend to insepct the content of the data file to understand why something is not mapping in the expected way.

As an example: in the case of GRIB time-like values are represented as integers like `20190101`, but *cfgrib* at the moment is forced to convert them into a fake CF representation before passing them to *xarray*, and when using `decode_times=False` a GRIB user is presented with something that has nothing to do with the on-disk representation.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,715374721
https://github.com/pydata/xarray/pull/4477#issuecomment-701622370,https://api.github.com/repos/pydata/xarray/issues/4477,701622370,MDEyOklzc3VlQ29tbWVudDcwMTYyMjM3MA==,226037,2020-09-30T20:19:21Z,2020-09-30T20:19:21Z,MEMBER,"Note that this PR doesn't change *xarray* behaviour unless the user sets the environment variable `XARRAY_BACKEND_API=v2`.

To test the new code paths you can use: `XARRAY_BACKEND_API=v2 pytest -v xarray/tests/test_backend*py`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,712247862
https://github.com/pydata/xarray/pull/4458#issuecomment-699960407,https://api.github.com/repos/pydata/xarray/issues/4458,699960407,MDEyOklzc3VlQ29tbWVudDY5OTk2MDQwNw==,226037,2020-09-28T11:55:08Z,2020-09-28T11:55:24Z,MEMBER,"@jhamman & @shoyer ping.

We'd like to have this (and optionally #4462) merged soon so we can more easily work on PR from master. Thanks!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,708766975
https://github.com/pydata/xarray/issues/4309#issuecomment-697952300,https://api.github.com/repos/pydata/xarray/issues/4309,697952300,MDEyOklzc3VlQ29tbWVudDY5Nzk1MjMwMA==,226037,2020-09-23T20:23:17Z,2020-09-24T15:12:18Z,MEMBER,"@shoyer & @jhamman just to give you an idea, I aim to see `open_dataset` reduced to the following:

```python
def open_dataset(filename_or_obj, *, engine=None, chunks=None, cache=None, backend_kwargs=None, **kwargs):
    filename_or_obj = nomalize_filename_or_obj(filename_or_obj)
    if engine is None:
        engine = autodetect_engine(filename_or_obj)
    open_backend_dataset = get_opener(engine)

    backend_ds = open_backend_dataset(filename_or_obj, **backend_kwargs, **kwargs)
    ds = dataset_from_backend_dataset(
        backend_ds, chunks, cache, filename_or_obj=filename_or_obj, **kwargs
    )
    return ds
```

Where the key observation is that `backend_ds` variable must be either `np.ndarray` or subclasses of `BackendArray`. That is backend should not be concerned with the in-memory representation of the variables, so they know nothign about `dask`, cache behaviour, etc. (@shoyer this was addressed briefly today)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,672912921
https://github.com/pydata/xarray/pull/4431#issuecomment-697924785,https://api.github.com/repos/pydata/xarray/issues/4431,697924785,MDEyOklzc3VlQ29tbWVudDY5NzkyNDc4NQ==,226037,2020-09-23T19:26:44Z,2020-09-23T19:26:44Z,MEMBER,"@jhamman I don't understand why 4f414f2 is shown here, it is a commit in master.

As for the rest, we re applied the engine selection refactor and added the new `zarr` bits.

All looks reasonable to me and all tests pass.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,703550109
https://github.com/pydata/xarray/pull/4431#issuecomment-696970366,https://api.github.com/repos/pydata/xarray/issues/4431,696970366,MDEyOklzc3VlQ29tbWVudDY5Njk3MDM2Ng==,226037,2020-09-22T20:45:53Z,2020-09-22T20:45:53Z,MEMBER,"Thanks @keewis! So it is correct, I wanted to reset to master and re apply the changes.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,703550109
https://github.com/pydata/xarray/pull/4431#issuecomment-696960812,https://api.github.com/repos/pydata/xarray/issues/4431,696960812,MDEyOklzc3VlQ29tbWVudDY5Njk2MDgxMg==,226037,2020-09-22T20:27:02Z,2020-09-22T20:27:02Z,MEMBER,"Woops I didn't know that force pushing a branch would close the PR :/

I'll try to reopen this PR or create a new one. Sorry for the noise.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,703550109
https://github.com/pydata/xarray/pull/4433#issuecomment-694662446,https://api.github.com/repos/pydata/xarray/issues/4433,694662446,MDEyOklzc3VlQ29tbWVudDY5NDY2MjQ0Ng==,226037,2020-09-18T05:34:17Z,2020-09-18T05:34:17Z,MEMBER,"Yes, please.

Minor: also I'd personally find even more intuitive the selection `da[[0, 2, 2], [1, 3]]` that still shows you can repeat indexes, but somewhat looks more like a downsampling. Your call.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,703991403
https://github.com/pydata/xarray/pull/4431#issuecomment-694411881,https://api.github.com/repos/pydata/xarray/issues/4431,694411881,MDEyOklzc3VlQ29tbWVudDY5NDQxMTg4MQ==,226037,2020-09-17T18:16:53Z,2020-09-17T18:17:14Z,MEMBER,"@jhamman: @shoyer  requested to keep this PR on hold until #4187 is merged as it will produce conflicts.

So I converted the PR to draft, after #4187 gets in, we will fix the conflicts and resubmit.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,703550109
https://github.com/pydata/xarray/pull/3166#issuecomment-692022706,https://api.github.com/repos/pydata/xarray/issues/3166,692022706,MDEyOklzc3VlQ29tbWVudDY5MjAyMjcwNg==,226037,2020-09-14T12:34:23Z,2020-09-14T12:34:23Z,MEMBER,"@jhamman & @shoyer the refactor of the big `if`-chain to a dictionary  in the form `{backend_name: backend_open}` is useful independently of the using the plugin interface, would make this PR smaller and may be useful in the bigger backend refactort.

If you don't mind I'll ask @TheRed86 to open a PR for this refactor alone.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,473795509
https://github.com/pydata/xarray/issues/4309#issuecomment-685928460,https://api.github.com/repos/pydata/xarray/issues/4309,685928460,MDEyOklzc3VlQ29tbWVudDY4NTkyODQ2MA==,226037,2020-09-02T18:46:58Z,2020-09-02T18:55:52Z,MEMBER,"@shoyer and @jhamman, I'm looking into the write support and if we let a backend return a `xr.Dataset`, as agreed, we lose the ability to support in-place change of a file, no update of attributes or `mode='a'`, unless the backend has a unambiguous way to identify persistent `xr.Dataset`.

I'm not sure what options for in-place change are supported, but I see at least `mode='a'` for zarr. Let's discuss this tomorrow.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,672912921
https://github.com/pydata/xarray/issues/4253#issuecomment-683350819,https://api.github.com/repos/pydata/xarray/issues/4253,683350819,MDEyOklzc3VlQ29tbWVudDY4MzM1MDgxOQ==,226037,2020-08-29T23:00:52Z,2020-08-29T23:00:52Z,MEMBER,"So weekly meeting every Thurday, perfect (cc @aurghs @TheRed86)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,663968779