Create gmt weekly/nightly builds?

[weiji14]

Issue:

Continuing the discussion from GenericMappingTools/pygmt#485. Just to emphasize that the nightly builds are not meant to be supported (and if that's a concern, I'm happy to close this issue). That said, it would help users wanting the latest bugfix and not wanting to compile from source.

I'm thinking if it's easier and more cross-platform if we build the gmt master branch via conda-build and then install it, i.e.,

1. Clone the gmt-feedstock. Only the files in the recipe directory are needed
2. Update the source section in the meta.yml file to use the master branch source from git
3. Build the gmt package via conda build recipe -c conda-forge.
4. Install the local conda package via conda install gmt-xxxx.tar.gz.

Originally posted by @seisman in GenericMappingTools/pygmt#485 (comment)

That's a smart idea. But we might as well make gmt-nightly builds a thing and pull that (and users who want the latest bugfix can benefit).

The Rapids AI organization has a good documented example, see e.g. cudf https://anaconda.org/rapidsai-nightly/cudf/files and blog post at https://medium.com/rapids-ai/in-the-heat-of-the-nightlies-6ed3be57ac64. I seem to recall they designed the build so it only happens if there's been commits, so no compute time is wasted. I'll open an issue for that later.

Originally posted by @weiji14 in GenericMappingTools/pygmt#485 (comment)

Environment (conda list):

$ conda list

Details about conda and system ( conda info ):

$ conda info

[weiji14]

Do you mean a separate gmt-nightly feedstock?

We actually have a devel branch in the gmt-feedstock, but I'm not sure if it's a good idea to have a nightly release, since the packages (Linux, macOS and Windows) would be almost 200 MB for each release.

Found this one conda-forge/cfep#3, but haven't read it yet.

Originally posted by @seisman in GenericMappingTools/pygmt#485 (comment)

Using the conda-forge/label/dev would probably do. We could make a 'weekday-only' or 'weekly' build instead if space is an issue (for reference, the libcudf nightly builds are ~130 MB each). Edit: Just as a reminder,gmt actually has a devel branch already (see #9 for how it started), so it should be 'easy' enough to just use that.

A separate gmt-nightly feedstock might be harder to maintain. The rapidsai cudf library is a bit more complex with GPU build dependencies and does theirs through an nvidia docker build. One benefit to this though, would be to avoid cluttering up the https://anaconda.org/conda-forge/gmt/files page.

[seisman]

Ping @leouieda and @ocefpaf for comments on this.

[ocefpaf]

While conda-forge does support some dev releases, in theory, we are a software repository for stable releases. With that said, I'm OK if you want to use the dev channel for that I just cannot help setting that up and supporting it.

[seisman]

Glad to know that at least conda-forge doesn't forbid it.

@weiji14 I like the idea of gmt dev builds. As one of the maintainers of the feedstock, I think I have the power to approve the idea. 😃

The dev builds can at least benefits:

• users who want to use the latest bugfix
• PyGMT, GMT.jl and anyone who want to check if anything in GMT breaks
• our try-gmt Jupyter lab which provides the gmt dev.

Some details:

• Build frequency: daily or weekly? I prefer weekly to not abuse the storage resource of conda-forge. Of course, we should be able to manually trigger a build if there are any critical bugfix
• We need to bump the build number for each build. How to do that? Ideally, we should have a github action which run a weekly cron job, bump the build number, create a PR, automatically merge it if CI pass (or at least ping the maintainers to manually review and merge it).
  

  gmt-feedstock/recipe/meta.yaml

  Lines 11 to 13 in b9f5aca

  	build:
  	number: 0
  	skip: True # [win and vc<14]