search

GenericMappingTools / pygmt

A Python interface for the Generic Mapping Tools.
https://www.pygmt.org
BSD 3-Clause "New" or "Revised" License
747 stars 216 forks source link

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

Closed moorepants closed 4 years ago

moorepants commented 4 years ago

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

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

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

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

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 https://github.com/GenericMappingTools/pygmt/pull/313#issuecomment-612856869 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 commented 4 years ago

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

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

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

weiji14 commented 4 years ago

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 :grinning:

weiji14 commented 4 years ago

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

moorepants commented 4 years ago

Thanks! Started here: https://github.com/conda-forge/staged-recipes/pull/11468

moorepants commented 4 years ago

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

weiji14 commented 4 years ago

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