Releases of netCDF-Java published at conda-forge

[cofinoa]

Hi all,

I’d like to highlight that netCDF-Java is available through the conda-forge channel, which can simplify installation and environment management, especially for users already working in the Python/R/conda ecosystem.

Package page:
https://anaconda.org/conda-forge/netcdf-java/files

This makes it possible to install netCDF-Java with:

conda install -c conda-forge netcdf-java

Some notes about the package:

• Versions 4 and 5 have been available over the past year (not every release yet, but if there is interest, I could extend coverage).

• The CDM utilities:
  https://docs.unidata.ucar.edu/netcdf-java/5.7/userguide/cdm_utility_programs.html
  are included as wrapper scripts (.sh for Unix/Linux, .bat for Windows):

  • ncj-ncdump
  • ncj-nccopy
  • ncj-nccompare
  • ncj-bufrsplitter
  • ncj-cfpointwriter
  • ncj-gribcdmindex
  • ncj-featurescan
  • ncj-catalogcrawler
  • ncj-toolsui (not documented as a utility, but included))

• The package also installs the required JVM alongside the utilities.

• One caveat: the conda-forge package distributes ToolsUI JAR, which is more complete and allows execution of ToolsUI.

I think it would be interesting to advertise this option in the documentation and release notes, and I’d like to encourage the community to try it and provide feedback.

It has proven very useful to me, and since updates are kept almost automatically in sync with upstream releases.

[lesserwhirls]

This is great @cofinoa! I would be happy to add this to the documentation and release notes going forward. I see the latest release on conda-forge is 5.9.1? There was a bug in the toolsUI jar that prevented it from being launch and required a toolsUI only 5.9.1.1 release. I've made a PR to the feedstock as an attempt to update (never worked with a feedstock before, so might not quite be right).

[cofinoa]

Thanks, Sean! Great to hear you’re open to including this in the docs and release notes.

Yes, 5.9.1 is the latest on conda-forge at the moment, and your PR to update the feedstock to 5.9.1.1 is exactly what’s needed to fix the ToolsUI issue. Thanks for jumping in on that!

It might also be a good idea to add another maintainer to the conda-forge recipe, just to help keep things up to date more smoothly. If you don’t mind, I have addded your GitHub username as a maintainer alongside mine when updating the feedstock. That way both of us could keep an eye on it going forward.

By the way, normally the conda-forge bot detects new upstream releases and automatically opens a PR to update the feedstock. Those PRs are not merged automatically by default, but they can be if auto-merge is enabled. Right now the typical workflow is to have a maintainer review and merge them manually.

One thing I’m not 100% sure about is how well conda-forge handles version numbers with four components like 5.9.1.1. It should work, but we may need to check if the bot and the versioning logic handle it smoothly. If it becomes problematic, we might have to tweak the recipe to align with conda-forge’s versioning expectations.

BTW, the rerender request in the PR wasn’t really necessary, but it was harmless.

[cofinoa]

BTW, I understand why version 5.9.1.1 was generated, but I noticed that only the toolsUI-*.jar was published as an asset, and not the netcdf-java-*.jar. Would it make sense to publish both jars to keep consistency with earlier releases?

[lesserwhirls]

I decided to go with a toolsUI jar only release, as it was the only jar impacted by the bug (a much simplified release only impacting those that use toolsUI, as opposed to a full blown netCDF-Java release). I started generating build info as part of the build process for toolsUI to use in its "about" menus and http user-agent strings. netCDFAll did not depend on this file, so I didn't attach it (and its checksums) as an asset. Under the hood, the gradle build generates a .properties file that is supposed to end up in the toolsUI jar, but due to something akin to a race condition, the file would not always end up written in time to be include. It worked when I tested the change during development, but when I built the release on a different machine, it was skipped (and the toolsUI jar failed to launch the application). I hope this is a one-time issue. I could retroactively generate the netCDFAll jar (and checksums) for the github repo release if useful, or I could try to remember to do that if we're ever in this situation again. Again, the actual bug had zero impact on anything else in the project outside of the toolsUI jar itself. But I'm happy to change things up if it is helpful :-)

[cofinoa]

Thanks a lot for the detailed explanation. From my perspective, it feels more like a rebuild, but I understand why you handled it this way. Right now it’s a bit unusual, but honestly I don’t see a “perfect” way of resolving it either.

In theory, one option would have been to edit the assets under the 5.9.1 release and re-upload the corrected jar, but I realize that can be seen as “politically incorrect” since it changes an already-published release.

In any case, the conda-forge releases are fine as they are, so no problem on that side.