Adding GliderTools

[jbusecke]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/GliderTools) and found some lint.

Here's what I've got...

For recipes/GliderTools:

• There are too few lines. There should be one empty line at the end of the file.
• about/license_family 'GNU' not allowed. Allowed families are AGPL,
  APACHE, BSD, CC, GPL, GPL2, GPL3, LGPL, MIT, MOZILLA, NONE, OTHER,
  PROPRIETARY, PSF, and PUBLIC-DOMAIN.
• requirements: run: astral>=2.2 must contain a space between the name and the pin, i.e. astral >=2.2
• requirements: run: netcdf4==1.5.4 must contain a space between the name and the pin, i.e. netcdf4 ==1.5.4
• requirements: run: scikit-learn>=0.22 must contain a space between the name and the pin, i.e. scikit-learn >=0.22
• requirements: run: seawater>=3.3 must contain a space between the name and the pin, i.e. seawater >=3.3
• requirements: run: tqdm>=4 must contain a space between the name and the pin, i.e. tqdm >=4
• requirements: run: xarray>=0.16.0 must contain a space between the name and the pin, i.e. xarray >=0.16.0
• noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

For recipes/GliderTools:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/GliderTools) and found some lint.

Here's what I've got...

For recipes/GliderTools:

• There are too few lines. There should be one empty line at the end of the file.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/GliderTools) and found it was in an excellent condition.

[jbusecke]

@lukegre I had to modify the license in the recipe here. Could you quickly double check that this info is correct?

[jbusecke]

There also seem to be some issues with the astral version pin on Linux (see here). Can we loosen that requirement?

[jbusecke]

Yeah astral upsets all of these builds. I think the reason is that I do get older versions of the package only on conda-forge:

 conda search astral -c conda-forge
Loading channels: done
# Name                       Version           Build  Channel
astral                         1.6.1            py_0  conda-forge
astral                         1.7.1            py_0  conda-forge
astral                         1.9.2            py_0  conda-forge

For conda-forge it seems that currently the dependencies can only point to other conda-forge packages.

Is astral a core dependency or can we make it optional? cc @lukegre @callumrollo

[jbusecke]

I started fixing the conda-forge version of astral, but it requires the approval of the upstream admins. Until that is resolved this is stalled.

[AdamTheisen]

@jbusecke I saw your comment on the astral feedstock. It looks like we were using it for something similar (sunrise/sunset) in our project, atmospheric data community toolkit (ACT). We ended up just getting rid of Astral as a dependency and switched to Skyfield. It was too much of a hassle to have to account for the conda astral version vs the latest on pypi. Not sure if it helps or not but here's the code.

https://github.com/ARM-DOE/ACT/blob/dc6635d7667ec97b658c01fb2ae949ef14753d3c/act/utils/geo_utils.py#L231

[callumrollo]

Thanks @AdamTheisen, I've looked at the codebase and we're only using astral for one calculation, shouldn't be too hard to switch.

@jbusecke Isabelle has volunteered to take this forward as she was already working on a bug in the astral implementation GliderToolsCommunity/GliderTools#56

[jbusecke]

If you think that this is a good solution, I am happy to close conda-forge/astral-feedstock#11. Thanks for the heads-up @AdamTheisen!

[AdamTheisen]

@jbusecke Not a problem! As one last note, skyfield does download a larger file with ephemeris data. We ended up trimming that file up, including it in our repo, and pointing skyfield to that file. Not sure if you have to use this without internet connection but just wanted to pass along.

Our file's located at
https://github.com/ARM-DOE/ACT/tree/master/act/utils/conf

[jbusecke]

That is indeed interesting and will be valuable to know for the CI to run smoothly. I'll see if I can perhaps cache that data using github actions.

[jbusecke]

Ok so the requirements seem to work now. But there are some weird errors when getting glidertools from pypi... Not sure if that is something temporary over at azure or if something is wrong with our pypi version. I think we might want to release a new version after GliderToolsCommunity/GliderTools#82 is merged, and then see if that fixes this.

[jbusecke]

Ill stop here for now and wait for another version that doesn't rely on setuptools_scm_git_archives anymore (I think they do not provide a conda package).

[jbusecke]

@conda-forge/staged-recipes I think this is ready to merge. Many thanks.

[ocefpaf]

Please, please, please move to gsw ;-p

[callumrollo]

Honestly not sure why we're still using seawater on this project. I've raised an issue and will hopefully make the switch to gsw. Be one less codebase depending on your deprecated library :p