issue_comments

thanks @alexamici

@shoyer I consider https://github.com/pydata/xarray/pull/2492/commits/486a391915d3bf1af685ae9ef908c30d5e053851 in a mergiable state if you like it.

I updated the description of the PR to sync with the new aim.

And we "refuse to guess"!

I broke the forrest of try / except to different functions with no real change (hopefully!) except _get_default_engine_grib.

Now opening a GRIB file without explicit engine raises an exception, but the error message suggests to the user to use the installed backend or to install one if none is present.

@shoyer if this too complex? Alternatively I can always return the same, generic, error message.

Totally agree with what @shoyer just wrote. I will add the pynio team is considering mothballing pynio in the relatively near future. So long term, we may not have to make a choice here but for now, I support asking the user to make an explicit decision.

cc @khallock

As someone who hasn't opened up a grib file for several years, I'm not in a good position to choose which backend to use by default. For now, I would be inclined to hold off on making a default choice (unless there is a clear consensus among other xarray devs/users) in favor of requiring users to be explicit. This is somewhat inline with the Zen of Python: "In the face of ambiguity, refuse the temptation to guess."

Probably the best user experience would be to raise an informative error suggesting the use of cfgrib or pynio when opening a grib but no engine is specified, e.g., ```

xarray.open_dataset('data.grib') ValueError: cannot open GRIB files without explicitly setting engine='pynio' or engine='cfgrib' in xarray.open_dataset() ```

@shoyer you are right, the GRIB translation is not unique and with cfgrib we have no plan to keep compatibility with PyNIO. I also agree that this will be really poor user experience 😞in some circumstances (even if in general it will work just fine). Do not merge yet!

We may default to one of the two without fall-back if it is not present (you may guess that I have a bias on which one to choose 😄), or keep the current behaviour.

In any event we can improve the error message by suggesting to add the engine= corresponding to the installed backends.

I'll show you what I mean.

Actually, thinking about this a little more, I'm not entirely sure it makes sense to fallback from using pynio to cfgrib. The problem is that these libraries may interpret GRIB files differently, e.g., with different variable names. It could make for a poor user experience for open_dataset('mydata.grib') to work differently when different dependencies are installed.

(please let me know if I'm mistaken here!)

Mm... the private functions in api.py are not unit tested as they are not part of the API, I'll add a test_backends_api.py for the _get_default_engine tests and then others can use it to unit test the other _ functions.

The whole engine detection strategy looks a bit fragile as the .gz extension is recognised outside of _get_default_engine and the nested ifs and try / except blocks make the code poorly readable. I can add a bit of a refactor in this area if you think it is appropriate.

Agreed! Yes, this would be welcome.

I'm happy with this change, but it would be good to ensure we have test coverage. It looks like we currently don't have any unit tests, but I'm pretty sure the other code is exercised by integration tests. If you're up for adding unit tests for _get_default_engine that would be awesome.