Alternative to udunitspy

[daf]

The udunitspy library is a swig wrapper (hard to install) around udunits, and udunits does not work/install on Windows properly.

@dpsnowden suggests perhaps making a pure python port (one may already exist) - I briefly looked and it seemed reasonable.

@abirger suggests perhaps a udunits webservice that can be optionally hit from the compliance-checker. We could make udunitspy an optional dependency and react to import failure in code properly.

[dpsnowden]

FWIW this exists http://coastwatch.pfeg.noaa.gov/erddap/convert/units.html

[daf]

Webservice? Awesome!

[ocefpaf]

@daf I went ahead and made a "iris_units" module from the iris package as discussed in #81. It is light weight and depends only on udunits2 and netcdf4-python, no swig! The installation is easy and works on windows, see our conda package.

However, I do not recommend using this yet. There will be some changes to avoid fork-fragmentation.

Meanwhile, here is an example comparing udunitspy and iris-units:

http://nbviewer.ipython.org/gist/ocefpaf/60ecac928612f5ae8fed

All that is required for compliance-checker is covered there.

[dpsnowden]

@ocefpaf please add the best repo for the units module you're working on to this issue thread so that the team can look into integrating it. Is it SciTools/cf_units or ocefpaf/cf_units ?

[ocefpaf]

https://github.com/ocefpaf/cf_units is my working fork of the official https://github.com/SciTools/cf_units.

The transition should be smooth (brave last words). I think I got almost of all of udunitspy functionality, used in compliance-checker, in the example here. However, I recommend waiting a little bit for a release. Here is our roadmap for the next days: SciTools/cf-units#15 (comment)

[lukecampbell]

My only issues with this approach are:

1. The library referenced still depends on the udunits shared library being installed.
2. ctypes is extremely prone to crashes. Due to the nature of using a duck-typed interpreted language of Python trying to call a strongly typed compiled language at runtime, there are lot's of chances to crash the application. My personal preference is Cython over both swig, ctypes and other binding supports.

I'm working on a lighter pure python implementation for udunits, but I don't have any idea when it will be done; but it will work on Windows and requires no compiled libraries (including XML).

[ocefpaf]

1. The library referenced still depends on the udunits shared library being installed.

Yes, but I disagree that this is a bad thing. Having a well established and widely used library (that is maintained by UNIDATA!) as a dependencies is a 👍 and not a 👎 . Also, by depending on udunits you remove the burden of maintaining/copying the xml definitions to a new library.

1. ctypes is extremely prone to crashes.

Can't comment on that, never had that issue using ctypes. All I can say is that cf_untis is used inside iris, it is well tested. Besides, better use ctypes (that is in the python standard library) than swig.

The swig wrapper around udunitspy does not work on Windows at the moment. I believe that cf_units is the shortest path to get compliance-checker on windows (with a tiny PR).

All that said:

I'm working on a lighter pure python implementation for udunits

Hey, I am all for it! 👍

[ocefpaf]

My personal preference is Cython over both swig, ctypes and other binding supports.

And here is the advantage of joining forces with other groups supporting open source libraries:

SciTools/cf-units#18

[daf]

This was resolved in #110/#114