MNT: Add noarch: python

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I've made the recipe noarch: python as instructed in #12.

Here's a checklist to do before merging.

• Bump the build number if needed.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• noarch: python recipes are recommended to have a lower bound on the python version. This recommendation will become a requirement in the future.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• requirements: run: python >= 3.6 should not contain a space between relational operator and the version, i.e. python >=3.6

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[weiji14]

Ping @moorepants (since you have more conda-forge experience), do you see an issue with moving to noarch Python builds here?

Also cc @seisman.

[seisman]

Is the pygmt package tested? I don't see any tests in the CI outputs.

[moorepants]

The imports are tested and that is sufficient here.

[moorepants]

If there is no import that would ensure the ctype code is executed, you can add an import that ensured that, or you can add a simple test file that ensures gmt function calls can be made.

[weiji14]

We could run pygmt.show_versions() I suppose to check that things are loaded?

Edit: done, and it seems to work fine:

+ python -c 'import pygmt; pygmt.show_versions()'
PyGMT information:
  version: v0.2.1
System information:
  python: 3.9.0 | packaged by conda-forge | (default, Oct 14 2020, 22:59:50)  [GCC 7.5.0]
  executable: $PREFIX/bin/python
  machine: Linux-4.15.0-1098-azure-x86_64-with-glibc2.12
Dependency information:
  numpy: 1.19.4
  pandas: 1.1.4
  xarray: 0.16.1
  netCDF4: 1.5.4
  packaging: 20.4
  ghostscript: 9.53.3
  gmt: 6.1.1
GMT library information:
  binary dir: $PREFIX/bin
  cores: 2
  grid layout: rows
  library path: $PREFIX/lib/libgmt.so
  padding: 2
  plugin dir: $PREFIX/lib/gmt/plugins
  share dir: $PREFIX/share/gmt
  version: 6.1.1

[moorepants]

The issue is that the test isn't run on windows anymore. I think you will need to check the installation on a Windows computer after this is merged to be sure.

[weiji14]

Yes, I'll keep this PR on hold until tomorrow perhaps (when I can access a Windows computer at uni).

[moorepants]

Ping @moorepants (since you have more conda-forge experience), do you see an issue with moving to noarch Python builds here?

As long as pygmt is a pure Python package and there are no differences in the installation for different OSes it is fine.

[moorepants]

Also add to the python in host, I believe.

[weiji14]

Oh yes, good catch.

[moorepants]

How does pygmt interact with gmt? You aren't compiling a Python C extension or anything?

[weiji14]

How does pygmt interact with gmt? You aren't compiling a Python C extension or anything?

That's a good question. I don't think we compile any C extensions, @seisman do you know anything about this?

[seisman]

How does pygmt interact with gmt? You aren't compiling a Python C extension or anything?

That's a good question. I don't think we compile any C extensions, @seisman do you know anything about this?

No C codes in the pygmt project. PyGMT calls GMT's shared library via ctypes.

[moorepants]

PyGMT calls GMT's shared library via ctypes.

As long as that works universally on the 3 OSes, then you should be able to do to noarch: python.

[weiji14]

Ok, noarch packages are up! I've installed it on Windows using conda install https://anaconda.org/conda-forge/pygmt/0.2.1/download/noarch/pygmt-0.2.1-pyhd8ed1ab_1.tar.bz2 and it seems to work-ish (though I'm getting an error, possibly due to GenericMappingTools/gmt#4441).

E           pygmt.exceptions.GMTCLibError: Module 'psconvert' failed with status code 78:
E           psconvert [ERROR]: System call [@gswin64c -q -dNOSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox -DPSL_no_pagefill -dMaxBitmap=2147483647 -dUseFastColor=true "C:/Users/username/.gmt/sessions/gmt_session.3708/gmt_30.ps-" 2> "C:/Users/username/.gmt/sessions/gmt_session.3708/psconvert_1804c.bb"] returned error 1.

.conda\envs\pygmt\lib\site-packages\pygmt\clib\session.py:506: GMTCLibError

But that's a separate issue I noticed before, and we'll sort that out upstream on GMT later.

Anyways, thanks @moorepants for the review!