search

conda-forge / gmt-feedstock

A conda-smithy repository for gmt.
BSD 3-Clause "New" or "Revised" License
7 stars 12 forks source link

Create gmt weekly/nightly builds? #95

Open weiji14 opened 4 years ago

weiji14 commented 4 years ago

Issue:

Continuing the discussion from https://github.com/GenericMappingTools/pygmt/pull/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 https://github.com/GenericMappingTools/pygmt/pull/485#issuecomment-647660874

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 https://github.com/GenericMappingTools/pygmt/pull/485#issuecomment-647720632


Environment (conda list):

``` $ conda list ```


Details about conda and system ( conda info ):

``` $ conda info ```
weiji14 commented 4 years ago

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 https://github.com/conda-forge/cfep/pull/3, but haven't read it yet.

Originally posted by @seisman in https://github.com/GenericMappingTools/pygmt/pull/485#issuecomment-647734037

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 commented 4 years ago

Ping @leouieda and @ocefpaf for comments on this.

ocefpaf commented 4 years ago

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 commented 4 years ago

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:

Some details: