Bump the required minimum GMT version to 6.1.0

[seisman]

Description of proposed changes

• Bump the required minimum GMT version to 6.1.0
• Fix some failing tests (only numbers, not baseline images) due to the change
  of default earth relief grid registration
• Remove compatibility codes for GMT 6.0
• Use pytest.mark.xfail to ignore some failures due to outdated baseline images or unknown failure reasons
• The Windows builds are disabled due to crashes
• The documentation building are disabled due to crashes on macos

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to docstrings or tutorials.

[seisman]

@weiji14 It's a little complicated here. In this PR, I bump the required minimum GMT version to 6.1.0. Apparently, there are tens of failures due to the change of default earth relief grid registration between GMT 6.0 and 6.1.

To fix these failing tests, I need to update the load_earth_relief() function:

1. Allow users to specify the grid registration of earth relief data
2. Support all resolutions from 01d to 01s
3. Allow users to specify a region, which is especially important for plotting high-resolution relief in small regions

Such changes may cause conflicts with your PRs #494 and #500, and this PR may be too large to fix so many things.

Maybe I should do only one thing in this PR (i.e., bumping the GMT version) and merge it although there are so many failing tests, then open more PRs to fix these failures one by one?

Do you have a better idea to make the 6.1.0 update simpler?

[weiji14]

Yeah, I agree with what you say, the load_earth_relief function needs to be redesigned first as in #489, but there's a bit of a chicken and egg situation since we need this 6.1.0 PR to do so. Ideally we would have the Github Actions CI doing a matrix build on GMT 6.0 and 6.1 first, but that's also a bit of a chore. This is one of the reasons I opened up #505 so as to reduce our dependency on load_earth_relief for our tests. Will need to have a longer think about this.

P.S. Don't mind the conflicts with those PRs. I would say that #500 actually supersedes #494 (will close it after #500 is merged), and it shouldn't be too hard to update them since they're quite small changes.

[weiji14]

Ok, after some thought, this is the master plan I've come up with:

• Step 0. Merge in Run Continuous Integration tests on Github Actions #475, to have Github Actions test on GMT 6.1. Optional, can proceed without and just run tests locally.
  • Tests pass on Travis/Azure Pipelines (GMT 6.0); fail (max, ~53) on GH Actions (GMT 6.1)
• Step 1. Merge in Allow load_earth_relief() to load pixel or gridline registered data #509 (partially resolves Redesign of the load_earth_relief() function #489) to allow for either pixel/gridline earth_relief grids. Use gridline in our tests
  • Tests pass on Travis/Azure Pipelines (GMT 6.0); fail (a lot, ~39) on GH Actions (GMT 6.1)
• Step 2. Merge in Initialize a GMTDataArrayAccessor #500 and Properly allow for either pixel or gridline registered grids #476 so that the virtualfile_from_grid mechanism works properly.
  • Tests pass on Travis/Azure Pipelines (GMT 6.0); fail (fewer, ~30?) on GH Actions (GMT 6.1)
• Step 3. Merge in this PR Bump the required minimum GMT version to 6.1.0 #507 that bumps minimum required GMT from 6.0 to 6.1, fix remaining test failures on GMT 6.1
  • Tests pass on Travis/Azure Pipelines (GMT 6.1); pass on GH Actions (GMT 6.1)
• Step 4. Cleanup. Do something about the duplicated Travis/Azure Pipeline/GH Actions CIs, also can think about removing backward compatibility with GMT 6.0.

[seisman]

We're bumping to GMT 6.1.0. I don't understand why we need to test both 6.0 and 6.1 now and remove GMT 6.0 backward compatibility later. We can make any changes to make PyGMT work with 6.1, even though the changes break 6.0.

[weiji14]

In that case, let's do 3 - 1 - 2. Just break things now and fix them as we go along (similar to the Windows fix before). I just don't have time today (paper response deadline) and didn't want the tests to be broken for so long.

[seisman]

Azure Pipelines have some technical issues which fail all our CI jobs. We need to wait for its recovery.

[weiji14]

Is there a timeline on when Azure Pipelines would be fixed? The SciPy sprint is coming up, and if that doesn't get resolved, we might need to fast track #475. But keep the Travis CI builds since they still run (and we need it to do the PyPI releases).

[seisman]

I thought it was fixed, but maybe not. See https://developercommunity.visualstudio.com/content/problem/1103514/schedules-devops-pipelines-failing-manual-reruns-w.html

[seisman]

@weiji14 I still think we should bump to 6.1.0 ASAP, and use the pytest.mark.xfail trick to "pass" the failing tests. It's not worth the effort making PRs compatible with both 6.0 and 6.1, and then remove the codes for 6.0 in just a few days.

[weiji14]

I'm ok with approving this PR and bumping to GMT 6.1.0 straightaway, but even if we do that, we still need to do #476 before we can update the baseline images. So go for it.

[seisman]

@weiji14 FYI, Azure Pipelines is back.

[seisman]

@weiji14 Welcome back. I merged three PRs (#512, #513 and #507) last night to make it work with GMT 6.1.0. Although these PRs were already merged, it would be better if you still give them a review and see if I made any mistakes.

[weiji14]

Cool, thanks for handling all of that! I've taken a quick look across all of them already and they seem fine, but I'll want to focus on the pixel/gridline registration issue today.

[seisman]

Yes, it has the highest priority.