Request of a non-alpha/beta release and installation via conda-forge channel

[moorepants]

Description of the desired feature

This project seems to be about 3 years old but is still alpha. I maintain infrastructure for a large organization and we have started supporting system package installations via conda, but we have policies on only installing official non-alpha/beta/rc releases as well as only installing from the official anaconda channels and conda forge. We have users interested in this package, but the current installation recommendations from the github source and the strict pinning to GMT 6.0.0 won't work for us. I'm requesting a non-alpha/beta/rc release of pygmt and that it is pushed to PyPi and Conda Forge. If there is a PyPi release, I can make the Conda Forge release if that is helpful.

Thanks. (and note that I don't know what gmt or pygmt are in a domain specialty sense or anything about the state of this project, just requesting from a sys admin perspective).

Are you willing to help implement and maintain this feature? Yes/No

I can maintain the conda forge feedstock.

[welcome]

👋 Thanks for opening your first issue here! Please make sure you filled out the template with as much detail as possible. You might also want to take a look at our contributing guidelines and code of conduct.

[weiji14]

Hi @moorepants, Just to double check that beta releases are fine? My thought is that a 0.1.0 should be possible, though I've been pushing for it since late last year 😆. The main blocker now is that using PyGMT with the Windows GMT conda package doesn't work #313, but using GMT built from source does (confusing I know).

if you're happy with a Linux/MacOS only release though, I can nudge @GenericMappingTools/python to get a PyPI 'beta' 0.1.0 release done, and we can work out the details of the conda-forge release together.

[moorepants]

Just to double check that beta releases are fine?

Technically no, but it may require a non-beta/alpha/rc for release via conda forge, which would be my ultimate goal. Not quite sure of their policies but in the past those releases have more hurdles to being made available.

To handle the windows issue, you could release without official windows support and the conda forge windows build could be disable. It at least would make it available for mac and linux. I personally only need Linux support for our system.

[weiji14]

Technically no, but it may require a non-beta/alpha/rc for release via conda forge, which would be my ultimate goal. Not quite sure of their policies but in the past those releases have more hurdles to being made available.

Ok, looking at semver, I think we could just release 0.1.0 without adding a -beta tag, if that's what is meant by beta. Major version '0.X.x' allows for changes to the public facing API (what I thought beta was), and I think pandas was on a non-1.0.0 release for a long time even though it's very stable.

To handle the windows issue, you could release without official windows support and the conda forge windows build could be disable. It at least would make it available for mac and linux. I personally only need Linux support for our system.

Sounds good, personally I'm on Linux as well, and our other developers use MacOS. Technically, Windows users can still install PyGMT from PyPI without any hurdles, it's just that they'll need to link it to a self-built GMT binary (i.e. conda-forge pygmt for windows is out of the question). There's a workaround for Windows using Windows Subsystem for Linux mentioned at #313 (comment) so we could point to that as an alternative.

Do you have a strict timeline on when this needs to happen? Some of the team are somewhat busy with the GMT 6.1.0 release or have classes to teach.

[moorepants]

if that's what is meant by beta

From a sys admin perspective of having to manage a distribution of a 1000+ compatible packages for end users and not knowing anything about specific packages we install, its nice to get the sense that an "official" packaged working version of a piece of software is available. Its also nice to install from packaged binaries instead of from source. For example, we don't upgrade Ubuntu to beta releases for all users, we install on test environments and if all looks good, we know that the upgrade to the next official Ubuntu release is likely to go well. Beta versions are for those that are willing to work with possibly unstable setups. We can also report bugs on beta releases. So, I'm hesitant to install anything that seems beta, alpha, rc, etc. for end user use. What you call your releases is ultimately up to you though.

If you follow sematic versioning, that's helpful as it gives a common understanding for meanings of stability and such.

timeline

There is nothing strict. We just had a request to support a class that is occurring now with a toolchain: gmt, pygmt, cartopy, pyshtools, etc. and we started trying to get support for that. We're trying to get it all working with no lead time to help switching to online courses at UC Davis. We have some work arounds so that end users can install non-persistent versions but students get bogged down with all the installation nightmares that come along with that. I opened the issue with no expected timeline, but wanted to express the need.

[leouieda]

Hi @moorepants, thanks for reaching out! I agree with @weiji14 that it's past time we made a 0.1 release. This is entirely my fault for letting the project lag for so long.

Yes, the plan was always to use semver. Since there are still large changes that will take place (definitely breaking the current API), we should release 0.1.0 with a large warning message that the API (functions and classes) will change in future releases. They can change dramatically until we reach 1.0.0, at which point we'll strictly strive for backwards compatibility. This warning should go on the front page (REAMDE) and in the install page I guess.

Release to PyPI should be as easy as creating a tag on Github. @weiji14 could you assign to the milestone anything you think needs to be done before then? You can remove anything that is not critical. I'll make the tag as soon as those are reached.

Thanks for offering help on the conda-forge recipe! I can be a maintainer as well since I have some conda-forge experience. Any help setting up the recipe would be appreciated. Our dependencies are set in requirements.txt with the exception of GMT>=6.0.0 since it's not on PyPI (but is on conda-forge).

@weiji14 one last thing, we should add instructions for installing from PyPI and conda-forge to the install page before making the release. Otherwise, the latest pages won't have that.

[moorepants]

@leouieda Sounds good. Let me know when you make a PyPi release and I'll start the conda forge submission process.

[weiji14]

Ok, sounds like everyone is up for it! I've opened up issue #418 to track the progress for the PyPI release. Let's move the discussion over there 😀

[weiji14]

@moorepants, we've released v0.1.0 on PyPI! We can start work on the conda-forge package now.

[moorepants]

Thanks! Started here: conda-forge/staged-recipes#11468

[moorepants]

I added @weiji14 and @leouieda as co-maintainers. If you all consent you'll need to comment that on the PR.

[weiji14]

Closed by conda-forge/staged-recipes#11468. Conda feedstock for PyGMT now maintained at https://github.com/conda-forge/pygmt-feedstock. Thanks @moorepants!