Release PyGMT v0.14.0

[seisman]

Release: v0.14.0
Scheduled Date: 2024/12/31
Pull request due date: 2024/12/28
DOI: 10.5281/zenodo.14535921

Priority PRs/issues to complete prior to release

• Add the 2024 AGU PyGMT talk and workshop to the documentation  #3683
  • Add the PyGMT talk at AGU24 to the "Overview" section #3685 @yvonnefroehlich
  • Add the GMT/PyGMT preworkshop at AGU24 to the "External resources" section #3689 @yvonnefroehlich
• Extend / Add gallery example to explain "symbol" parameter of "Figure.plot" #3595
  • DOC: Add basic tutorial "Plotting single-parameter symbols" #3598 @yvonnefroehlich
  • Add Figure.scatter #3602 @seisman
• SPEC 0
  • Add support for Python 3.13 #3490 @weiji14
  • SPEC 0: Bump minimum supported version to Python 3.11 #3606
  • SPEC 0: Bump minimum supported version to NumPy 1.25 #3697
• GMTDataArrayAccessor
  • Add enums GridRegistration and GridType for grid registration and type #3693
  • GMTDataArrayAccessor: Support passing values using enums GridRegistration and GridType for grid registration and type #3696
• Figure.hlines Add Figure.hlines for plotting horizontal lines #923
• Figure.vlines Add Figure.vlines for plotting vertical lines #3726
• Get rid of temporary files in grdcut and netCDF4
  • **BREAKING** pygmt.grdcut: Refactor to store output in virtualfiles for grids #3115
  • Add pygmt.gmtread to read a dataset/grid/image into pandas.DataFrame/xarray.DataArray #3673
  • Remove the dependency of netCDF4 #3643
• BREAKING: Support typesetting apostrophe (') and backtick (`) #3105
• Remote datasets
  • Remote datasets: Add "load_earth_dist" to load "GSHHG Earth distance to shoreline" dataset #3706 @yvonnefroehlich
  • Remote datasets: Add "load_earth_mean_sea_surface" to load "CNES Earth Mean Sea Surface" dataset #3717 @yvonnefroehlich
  • Remote datasets: Add "load_earth_mean_dynamic_topography" to load "CNES Earth Mean Dynamic Topography" dataset #3718 @yvonnefroehlich
  • Remote datasets: Add "uncertainty" parameter to "load_earth_free_air_anomaly" to load the "free-air anomaly uncertainty" dataset  #3727 @yvonnefroehlich
  • Remote datasets: Add load_earth_deflection to load "IGPP Earth east-west and north-south deflection" datasets #3728 @yvonnefroehlich

Before release:

• Check SPEC 0 to see if we need to bump the minimum supported versions of GMT, Python and core package dependencies (NumPy, pandas, Xarray) @seisman
• Review the "PyGMT Team" page @seisman
• Check to ensure that:
  • Deprecations and related tests are removed for this version by running grep --include="*.py" -r vX.Y.Z from the base of the repository @seisman
  • All tests pass in the "GMT Legacy Tests" workflow
  • All tests pass in the "GMT Dev Tests" workflow
  • All tests pass in the "Doctests" workflow
• Update warnings in pygmt/_show_versions.py as well as notes in Not working transparency regarding GMT-Ghostscript incompatibility
• Reserve a DOI on Zenodo by clicking on "New Version" @seisman
• Finish up the "Changelog entry for v0.x.x" Pull Request (Use the previous changelog PR as a reference)
• Run make codespell to check common misspellings. If there are any, either fix them or add them to ignore-words-list in pyproject.toml
• Draft the announcement on https://hackmd.io/sxVhw5ReS3OVoeHgDmAxtA

Release:

• At the PyGMT release page on GitHub:
  • Edit the draft release notes with the finalized changelog
  • Set the tag version and release title to vX.Y.Z
  • Make a release by clicking the 'Publish Release' button, this will automatically create a tag too
• Download pygmt-X.Y.Z.zip (rename to pygmt-vX.Y.Z.zip) and baseline-images.zip from
  the release page, and upload the two zip files to https://zenodo.org/deposit,
  ensure that they are filed under the correct reserved DOI

After release:

• Update conda-forge pygmt-feedstock pygmt v0.14.0 conda-forge/pygmt-feedstock#38
  [Done automatically by conda-forge's bot. Remember to pin Python and SPEC0 versions]
• Bump PyGMT version on https://github.com/GenericMappingTools/try-gmt (after conda-forge update) Bump to PyGMT v0.14.0 try-gmt#56
• Announce the release on:
  • GMT forum (do this announcement first! Requires moderator status)
  • ResearchGate (after forum announcement, add new version as research item via the code category, be sure to include the corresponding new Zenodo DOI)

---

• Party 🎉 (don't tick before all other checkboxes are ticked!)

[seisman]

@GenericMappingTools/pygmt-maintainers I think it's time to prepare for the v0.14.0 release. I've set the release date to 2024/12/31, but it's OK to postpone it to early Jan. 2025, depending on the amount of final changes that we want to make to the v0.14.0 release.

[yvonnefroehlich]

@GenericMappingTools/pygmt-maintainers I think it's time to prepare for the v0.14.0 release. I've set the release date to 2024/12/31, but it's OK to postpone it to early Jan. 2025, depending on the amount of final changes that we want to make to the v0.14.0 release.

I have added some of my pending PR, but probably a bit ambious to finish them all for v0.14.0.
Would prefer to move the release not too much into January, as it will be likely that I will be only limited available for the first month / half of 2025.

[seisman]

I have added some of my pending PR, but probably a bit ambious to finish them all for v0.14.0.

PRs/Issues that we have set the v0.14.0 milestone can be tracked at https://github.com/GenericMappingTools/pygmt/milestone/20. We may finish them or not depending on our availability. In the release checklist, I think we should only list the high-priority PRs/issues that must be finished prior to the release.

[weiji14]

I have added some of my pending PR, but probably a bit ambious to finish them all for v0.14.0.
Would prefer to move the release not too much into January, as it will be likely that I will be only limited available for the first month / half of 2025.

PRs/Issues that we have set the v0.14.0 milestone can be tracked at https://github.com/GenericMappingTools/pygmt/milestone/20. We may finish them or not depending on our availability. In the release checklist, I think we should only list the high-priority PRs/issues that must be finished prior to the release.

We can keep the release to be end of December. @seisman, I feel that the PRs around making NetCDF4 optional and pygmt.read might need more time, would probably push that to the v0.15.0 release. The PR at #3115 can probably get in though, I should have time to review next week around Christmas break.

[seisman]

@GenericMappingTools/pygmt-maintainers

I plan to merge PRs #3722, #3727, and #3726 tomorrow (2024/12/28) and then start working on the release changelog. From 12/28 to 12/31, documentation changes like #3720, and #3711 can still be merged, but no more other code changes (#2431 may be an exception depending on the progress).

[seisman]

I've created a draft release announcement at https://hackmd.io/sxVhw5ReS3OVoeHgDmAxtA.

[yvonnefroehlich]

I've created a draft release announcement at https://hackmd.io/sxVhw5ReS3OVoeHgDmAxtA.

Thanks @seisman for starting to work on the draft release announcement, I made some additions and updates.

[seisman]

There is still one failure in the "GMT Dev Tests" workflow:

________________________ test_sphinterpolate_no_outgrid ________________________

mars =      longitude  latitude  radius_m
0      278.231   -40.059      6888
1      302.360    15.487      -233
2       57.10...8.384   -32.260      1375
368    312.032    22.271     -4400
369    134.260    47.670     -3820

[370 rows x 3 columns]

    @pytest.mark.benchmark
    def test_sphinterpolate_no_outgrid(mars):
        """
        Test sphinterpolate with no set outgrid.
        """
        temp_grid = sphinterpolate(data=mars, spacing=1, region="g")
        assert temp_grid.dims == ("lat", "lon")
        assert temp_grid.gmt.gtype == 1  # Geographic grid
        assert temp_grid.gmt.registration == 0  # Gridline registration
        npt.assert_allclose(temp_grid.max(), 14628.144)
        npt.assert_allclose(temp_grid.min(), -6908.1987)
        npt.assert_allclose(temp_grid.median(), 118.96849)
>       npt.assert_allclose(temp_grid.mean(), 272.60593)
E       AssertionError: 
E       Not equal to tolerance rtol=1e-07, atol=0
E       
E       Mismatched elements: 1 / 1 (100%)
E       Max absolute difference among violations: 0.00024763
E       Max relative difference among violations: 9.0836965e-07
E        ACTUAL: array(272.60568, dtype=float32)
E        DESIRED: array(272.60593)

It's likely caused by xarray changes.

[seisman]

I've made the v0.14.0 release and everything works fine, but the "Publish to PyPI" workflow fails https://github.com/GenericMappingTools/pygmt/actions/runs/12561955854/job/35021691730:

Error: Attestation generation failure: /github/workspace/dist/pygmt-0.14.0.tar.gz already has a publish attestation: /github/workspace/dist/pygmt-0.14.0.tar.gz.publish.attestation

So v0.14.0 is not available on PyPI yet.

This upstream issue pypa/gh-action-pypi-publish#283 explains the reason. In short, it's because the action (actually the twine tool called in this action) generates the attestation file (https://github.blog/news-insights/product-news/introducing-artifact-attestations-now-in-public-beta/), and it fails if a attestation file already exists. So, our CI job fails because we use the action twice, for TestPyPI and PyPI, respectively.

The issue also provides many solutions, e.g.,

• Set attestations: false Producing attestations fails when attempting publishing from unsupported reusable workflows (when enabled) pypa/gh-action-pypi-publish#283 (comment)
• Use separate jobs for the TestPyPI and PyPI uploads: Producing attestations fails when attempting publishing from unsupported reusable workflows (when enabled) pypa/gh-action-pypi-publish#283 (comment)
• Disable TestPyPI uploads for releases.

We need to decide what to do with the workflow, but before that we need to decide what to do with v0.14.0 release. We can either manually upload v0.14.0 to PyPI or have a v0.14.1 release after fixing the workflow.

[seisman]

We need to decide what to do with the workflow, but before that we need to decide what to do with v0.14.0 release. We can either manually upload v0.14.0 to PyPI or have a v0.14.1 release after fixing the workflow.

I've decided to manually upload v0.14.0 following instructions at https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#packaging-your-project. Now v0.14.0 is on PyPI.