switch to pygrib?

[bblay]

It has been asked whether we should switch to pygrib.
This might facilitate use of Iris with grib files on Windows.

A comment from 2010:
 

I believe we're going to need to use the gribapi rather than pygrib,
as pygrib doesn't provide access to all the features - most notably new_from_samples().
Also, it's better for staying up-to-date with the grib spec, and has ecmwf's support.

The objection about creating new messages shouldn't be prohibitive as we could provide our own samples.
In fact, since then:

On the pygrib page ( https://code.google.com/p/pygrib/) it says:
 
"This module contains python interfaces for reading and writing GRIB data using the ECMWF GRIB API C library, and the NCEP GRIB2 C library, as well as command-line utilites for listing and re-packing GRIB files.
 
"a new module ncepgrib2 has been added to provide a python interface to this library. It's most useful feature is it's ability to encode new grib messages from scratch."

So the remaining questions to consider:
 - is there enough functionality available in pygrib for our current and future needs?
 - is this a desirable change?
 - what are the other options?
   - encourage ECMWF to provide the Python interface for Windows.
   - find our own way to build the ECMWf Python interface for Windows and feed back to ECMWF.

[marqh]

I am not yet convinced of the validity of this approach.

1. It is another dependency to add to the stack.
2. If the driver is GRIB on windows, I am not sure this is a solution, as pygrib relies on cygwin for windows capability, a fragile and not pretty approach.
3. If the driver is functionality, then that is a little different,
   
1. I am interested in the ability to code GRIB messages from scratch, and not work from samples to create new messages, the sample approach has issues with validating translations and persisting default values.
2. There may be other functional reasons why this interface is valuable which I am not aware of
   

I think an investigation into capabilities may be worthwhile on these grounds

I think that this activity, if it takes place, should also consider the approach of refactoring the gribapi Python interface to deliver the capabilities we require

Both of these thought processes seem to me to require that we understand what we want to do with the GRIB interface, so that should be in scope too.

[bblay]

I agree on all counts, @marqh.

...should also consider the approach of refactoring the gribapi Python interface to deliver the capabilities we require

I started gribby on the back burner with this in mind, hoping to develop it enough to interest ECMWF in switching to it.
I expect it would "just work" on Windows because it uses ctypes, although not investigated enough to be sure.