Deprecate udunitspy.

[ocefpaf]

udunitspy is no longer developed and not used by any other package in the IOOS stack.

Note that deprecation will prevents future builds, but the old ones are still available in the binstar channel.

[emiliom]

Sorry to parachute here ... I've never used udunitspy, but I've been aware of it, I can see what it is/was for, and it's been on my indefinite list of to-do's to try it out. Is the recommended replacement cf_units?. Since udunitspy was developed by ASA, can someone add a prominent blurb on its github repo stating that it's no longer developed, and recommending cf_units instead?

Thanks.

[ocefpaf]

The no longer developed was my conclusion due to low udunistpy repository activity. Note that I am biased here, since I am the one pushing for Scitools cf_units 😜

The only module, that I know of, using udunitspy was compliance-checker (CC). The latest CC version changed to cf_units. The advantages of that transition is that now CC works on Windows, and it is built on top of a units library that has a "bigger community" than udunitspy.

PS: I have a blog post comparing both. Most of the examples in the post are the required modifications to migrate from udunitspy to cf_units.

[emiliom]

Thanks for your reply. Nice blog post! My suggestion about making the udunitspy deprecation more official was coming from a broader IOOS perspective, to help steer the IOOS Python community towards the better packages for any given functionality, when there's an obvious choice. @lukecampbell, are you aware of any dependencies on udunitspy in the IOOS Catalog infrastructure you're involved in, or anywhere else?

[rsignell-usgs]

I couldn't find any packages using udunitspy either. @kwilcox, I did find a package that could probably use cf_units though... https://github.com/asascience-open/paegan/blob/d14ae9431bfcccb95b1cdb826dafe7202bdbe4df/paegan/cdm/depthvar.py#L7-L24

[emiliom]

Coincidentally I ran into a recent question elsewhere (from outside IOOS) from someone wondering about udunitspy vs "cfunits-python". cfunits-python seems to be based on the active cf-python package, which I didn't know about until now. cfunits-python is not the same as the cf_units package addressed here, and it seems to have been replaced or folded into the cf.Units class in cf-python.

I'm mentioning all this here at least in part to link up with @jhamman here at the University of Washington Hydro | Computational Hydrology group. I didn't know Bart's group was so much into Python, and I can see that @ocefpaf has already been in touch with @jhamman, but regarding nco-bindings. Cool! Joe: I know Bart really well. I should (re)connect with him and you soon ...

Apologies again for twisting and extending this otherwise narrow pull request!

[ocefpaf]

Apologies again for twisting and extending this otherwise narrow pull request!

@emiliom no problem! This kind of discussion is important to avoid the re-invention of the wheel every now and then.

I believe that iris.units (now cf_units) had a common origin with cfunits-python, not sure though. I looked at both codes before investing my time in cf_units and I can say that cf_units has better support for multiple platforms and a larger community around.

cf-python is another discussion that we need to have at some point. Iris netcdf loader does a great job of handling CF-rules. @rsignell-usgs and I have this dream of making the netcdf loader a stand alone CF-package like we did with cf_units, but I am not familiar enough with the code to say that this is even possible.

(Pinging @pelson and @rhattersley here 😜)

[rhattersley]

@rsignell-usgs and I have this dream of making the netcdf loader a stand alone CF-package

What would be the result of a load?

Are either of you going to be at SciPy 2015? I can't make it, but @pelson will be there and a face-to-face session would probably be the quickest way to make progress.

[ocefpaf]

Are either of you going to be at SciPy 2015?

We are both going. (I got a last minute financial aid.)

We'll do our best to steal @pelson to the dark side and bride him with a few 🍻 to get our way 😈

(Sorry to hear that you are not going.)

What would be the result of a load?

Now... that is the big question! To be completely honest we are not sure. And we are open to your carefully designed ideas 😉

For example, right now both @rsignell-usgs and I use iris as a CF-compliance checker. If the data loads in iris that means the data are OK. Also, accessing/querying parts of a netcdf_file or an OPeNDAP endpoint using standard_names is much better than using the netCDF vars.

I know that the logic answer would be: Just use the iris cube. However, we would like to do that without installing iris and all its dependencies. That would allow us to use this in other projects like pysgrid.

We see a lot of code repetition when it comes to interpret the CF-conventions. It would be nice to have this "imaginary module" to enforce the CF-rules for us, like iris does via pyke, and return a "generic" object or an enhanced netCDF object that could be used to construct an iris cube, a xray.Dataset, or anything else. Makes sense?

[kwilcox]

I agree 100% with @ocefpaf. I've always wanted some piece of software on top of netcdf4-python that provides a higher level interface to CF netCDF files. I've got many different projects on many different levels of maturity that attempt to do this, but none do it very well.

Ideally, I'd like to see the interface return some EnhancedDataset object with standardized high level functions that provide consistent data access no matter the modeling grid you are dealing with (rgrid, sgrid, ugrid, dsg, etc.). Under the hood, it could use the targeted libraries popping up (https://github.com/sgrid/pysgrid, https://github.com/pyugrid/pyugrid) to provide said interface. Think along the lines of get_data(variable_name, time_slice, bbox, depth) no matter the grid you are dealing with. Disclaimer iris might already do this, I haven't experimented with iris in awhile.

[jhamman]

@emiliom - Thanks for getting in touch. You can expect a personal communication from me shortly.

@kwilcox - have you seen xray. It may have some of the enhanced dataset functionality you describe. Basically it is Pandas meets netCDF4. Cool stuff.

All - does ioos have a gitter space. The kind of conversation we're having here may fit better outside of this PR.

[emiliom]

Yeah, the topics have gotten much broader than the original PR. But fun topics!

@ocefpaf, you can shift this thread(s) to another venue as you see fit. @jhamman -- hi! I'd never heard of gitter, but it sounds intriguing.

[ocefpaf]

does ioos have a gitter space. The kind of conversation we're having here may fit better outside of this PR.

We do now and I will "copy and paste" the relevant parts of this thread there tomorrow.

PS: @jhamman even xray would benefit from such a module, at least for domain specific applications. We are talking about being strict with the CF-rules, when loading and creating an object, and not all the other nice things that xray adds to the Dataset object.