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.

@shoyer, I also agree that requiring a backend to be explicitly selected for grib files would be a better solution from a user experience perspective, as opposed to silently replacing PyNIO with cfgrib (inconsistent variable names would be a major concern).

As @jhamman mentioned, we have been evaluating the long-term viability of PyNIO and are considering putting it into "maintenance mode". Unfortunately, the lead developer of PyNIO retired last year, and we don't have the budget to replace him at this time.

We intend to continue fixing bugs in PyNIO as necessary (versions 1.5.1, 1.5.2, and 1.5.3 have all been released in the last three months), and we will also continue supporting the conda-forge/pynio-feedstock recipe. However, no new functionality (such as updating/adding grib tables) is part of our current long-term plan for PyNIO.

(cc'ing @marylhaley in case she has any additional input to offer)

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.

Hello @alexamici! Thanks for submitting the PR.

• There are no PEP8 issues in the file xarray/backends/api.py !

• There are no PEP8 issues in the file xarray/core/utils.py !