Added conda build recipe and build script

[ceblanton]

"conda build ." worked on the workstations, and conda install worked on the thin client.

224

[ceblanton]

Ideally, the conda build could happen through the github CI, and if successful, then it would publish to the noaa-gfdl anaconda channel:

https://anaconda.org/noaa-gfdl

For new releases (new git tags), we would want the published conda package to have the same version/tag.

For pushes to the main branch, we could have the published conda package have a test or develop version.

[underwoo]

I think it is better to keep the conda recipe in a different repository. We do not want to create a new conda binary package frequently, and only after we mint a release.

On Mon, Nov 13, 2023 at 11:00 Chris Blanton @.***> wrote:

Ideally, the conda build could happen through the github CI, and if successful, then it would publish to the noaa-gfdl anaconda channel:

https://anaconda.org/noaa-gfdl

For new releases (new git tags), we would want the published conda package to have the same version/tag.

For pushes to the main branch, we could have the published conda package have a test or develop version.

— Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/FRE-NCtools/pull/225#issuecomment-1808718518, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJUSYNXHPWHNXIZU64I6LYEJN47AVCNFSM6AAAAAAX6E3VF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYG4YTQNJRHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ceblanton]

@underwoo thanks for the suggestion, but how is the frequency of conda binary releases related? Regardless of where the conda recipe is stored, we'll only release a conda binary once per release. I sort of see the advantage of keeping the recipes separate, in that build-only changes won't clutter up the source repository.

Hopefully, soon we'll have several conda and spack recipes, e.g. spack and conda recipes for fre-nctools, hsm, and the new fre-cli. Should they all be together (e.g. NOAA-GFDL/conda-recipes), or one recipe collection per package (e.g. NOAA-GFDL/fre-nctools-recipes)?

[underwoo]

For now, I think a single repository for all the recipes. For an example look at how conda-forge does it. While they do have separate repositories for the recipes, they combine them in a feedstock repository. We can separate them later if the one repository becomes too unwieldy.

[ceblanton]

Thanks, @underwoo. That sounds like a plan- one NOAA-GFDL repository for all conda recipes, like conda-forge. Can you create the repository, or is there a form for that? I think we would want it in the least surprising public place (https://github.com/NOAA-GFDL/conda-recipes). The individual recipes would be a subdirectory that could be a submodule as needed (e.g. recipes/fre-nctools).

Although, I wonder if we should raise the ante and make our recipes officially part of conda-forge. We can always do that later, I suppose. (conda-forge requires that all prerequisites be also in conda-forge, I think, so may be difficult for some packages).