Fortran dependency could be resolved with wheels posted to pypi

[jccurtis]

I just found this package after searching for some time for spherical surface interpolation methods (I really don't understand why this isn't in scipy...) My comments for improvement are:

• to enable the pypi deployment and upload the wheels (no fortran needed for pip install like scipy, etc.)
• enable testing for python2 since it is supported in the setup.py

Apologies for any typos/terse statements, I have a broken arm right now and am typing with one hand 😅

[lmoresi]

Agreed - looking into this (and, indeed, conda install) since the CI/CD that we use allows us to choose multiple platforms and build / upload binaries. We are phasing out python2 as this is a side-project that we want to keep as lean as we can.

I'm working with a broken leg right now. I wish it was possible to upload a new patch to fix these things. Good luck.

[jccurtis]

Thanks for the prompt response @lmoresi! I can take a look this weekend and check about the pypi upload. conda install would also be awesome! Our research group is unfortunately stuck supporting python2 since we are using ROSv1 which is built against python2 in their Ubuntu apt infrastructure but this can be worked around with optional deps. I'm just counting the days until Ubuntu 20.04 and no more from __future__ ...

Best wishes with the broken leg!

[lmoresi]

Happy to have help / collaboration on this. The python 2 issue is just us being complacent and we would be happy to have that looked into.

Same with binary releases - we just lack experience in how to get coverage of all the required platforms in some easy-to-automate workflow. We are moving to github actions in the repository to try to make this a fully collaborative enterprise.

[jccurtis]

Regarding Travis this seems pretty straightforward. I haven’t found a good reference or example for GH actions for bdist CD on PYPI (yet).

See: https://docs.travis-ci.com/user/deployment-v2/providers/pypi/

[jccurtis]

Update, thanks for getting macOS wheels on pypi for v1.2.0!

$ pip install stripy
Collecting stripy
  Downloading stripy-1.2.0-cp37-cp37m-macosx_10_13_x86_64.whl (10.4 MB)
     |████████████████████████████████| 10.4 MB 6.4 MB/s
Collecting numpy
  Using cached numpy-1.18.1-cp37-cp37m-macosx_10_9_x86_64.whl (15.1 MB)
Collecting scipy>=0.15.0
  Using cached scipy-1.4.1-cp37-cp37m-macosx_10_6_intel.whl (28.4 MB)
Installing collected packages: numpy, scipy, stripy
Successfully installed numpy-1.18.1 scipy-1.4.1 stripy-1.2.0

I see this was uploaded with a partially completed action](https://github.com/underworldcode/stripy/runs/486514997?check_suite_focus=true) but the linux still fails due to the invalid platform tag:

HTTPError: 400 Client Error: Binary wheel 'stripy-1.2.0-cp37-cp37m-linux_x86_64.whl' has an unsupported platform tag 'linux_x86_64'. for url: https://upload.pypi.org/legacy/

Thus I see you are using the RalfG/python-wheels-manylinux-build action which uses this docker container. I think the issue is the abi tag you are using. This docker contains the following python version / abi combos:

$ docker run -it quay.io/pypa/manylinux2010_x86_64 /bin/bash
$ ls /opt/python/
cp27-cp27m  cp27-cp27mu  cp35-cp35m  cp36-cp36m  cp37-cp37m  cp38-cp38

@lmoresi Try changing this line from:

        python-versions: 'cp36-cp36m cp37-cp37m cp38-cp38m'

to

        python-versions: 'cp27-cp27m cp36-cp36m cp37-cp37m cp38-cp38'

(yes I added the py27 version 😉 )

[lmoresi]

This should make everyone quite happy. I'm closing this for the time being. There are issues with the conda build that works fine on mac with py37 (and not much else) but fails on ubuntu. I would like to fix this but will raise a separate issue for it.

[jccurtis]

Excellent. My apologies if my verbose notes added noise or confusion (I am learning all this too 😊). I’m glad the manylinux fix worked out! Thanks again!