Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 0 additions & 12 deletions pygmt/__init__.py
Original file line number Diff line number Diff line change
Expand Up @@ -146,17 +146,6 @@ def _get_ghostscript_version():
continue
return None

def _get_gmt_version():
"""
Get GMT version.
"""
try:
return subprocess.check_output(
["gmt", "--version"], universal_newlines=True
).strip()
except FileNotFoundError:
return None

sys_info = {
"python": sys.version.replace("\n", " "),
"executable": sys.executable,
Expand All @@ -176,7 +165,6 @@ def _get_gmt_version():
for modname in deps:
print(f" {modname}: {_get_module_version(modname)}")
print(f" ghostscript: {_get_ghostscript_version()}")
print(f" gmt: {_get_gmt_version()}")

print_clib_info()

Expand Down
6 changes: 5 additions & 1 deletion pygmt/clib/session.py
Original file line number Diff line number Diff line change
Expand Up @@ -158,7 +158,8 @@ def info(self):
self._info = { # pylint: disable=attribute-defined-outside-init
"version": self.get_default("API_VERSION"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From #1830 (comment), you said:

2. The GMT version information gmt: 6.4.0_434ed18_2022.03.11 is obtained by calling gmt --version. However, when multiple GMT versions are installed, the command gmt and the library libgmt may come from different GMT versions. For example, if I have GMT 6.3 in my conda environment and GMT dev in another installation path, PyGMT may load the GMT 6.3 library but find GMT dev comman, or vice versa, depending on the settings of PATH and GMT_LIBRARY_PATH. It causes some confusion because PyGMT reports inconsistent GMT versions. I think we should remove the gmt: 6.4.0_434ed18_2022.03.11 information.

So we will only have 6.4.0 printed out. This is ok for most users who install the offficial release versions, but for those who install the dev versions, I think it's useful to have the git short-hash and date part too, so that we can know the exact GMT dev version we've installed.

Just as an idea, how about we check the two strings? If there are equal (e.g. 6.4.0 and 6.4.0), we just print one. But if they are different, then print both? Alternatively, is there a way to get the exact version from the GMT API somehow?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From #1830 (comment), you said:

  1. The GMT version information gmt: 6.4.0_434ed18_2022.03.11 is obtained by calling gmt --version. However, when multiple GMT versions are installed, the command gmt and the library libgmt may come from different GMT versions. For example, if I have GMT 6.3 in my conda environment and GMT dev in another installation path, PyGMT may load the GMT 6.3 library but find GMT dev comman, or vice versa, depending on the settings of PATH and GMT_LIBRARY_PATH. It causes some confusion because PyGMT reports inconsistent GMT versions. I think we should remove the gmt: 6.4.0_434ed18_2022.03.11 information.

So we will only have 6.4.0 printed out. This is ok for most users who install the offficial release versions, but for those who install the dev versions, I think it's useful to have the git short-hash and date part too, so that we can know the exact GMT dev version we've installed.

Yes, I agree.

Just as an idea, how about we check the two strings? If there are equal (e.g. 6.4.0 and 6.4.0), we just print one. But if they are different, then print both?

We still have the same problem. When multiple GMT versions are installed, we may load the libgmt from GMT version A and call GMT CLI from GMT version B.

Alternatively, is there a way to get the exact version from the GMT API somehow?

I just checked the GMT source code. It's impossible to get the version string 6.4.0_434ed18_2022.03.11 from GMT API.

Since we can know the GMT library path library path: /Users/user/opt/GMT-master/lib/libgmt.dylib, perhaps we can assume that the relative path to the GMT command is {library path}/../bin/gmt? Or we can ask GMT to report the version string 6.4.0_434ed18_2022.03.11 through GMT API?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, is there a way to get the exact version from the GMT API somehow?

I just checked the GMT source code. It's impossible to get the version string 6.4.0_434ed18_2022.03.11 from GMT API.

Since we can know the GMT library path library path: /Users/user/opt/GMT-master/lib/libgmt.dylib, perhaps we can assume that the relative path to the GMT command is {library path}/../bin/gmt? Or we can ask GMT to report the version string 6.4.0_434ed18_2022.03.11 through GMT API?

Getting it through the GMT API seems like the most robust solution, rather than having to guess where the actual GMT binary PyGMT is using is located on the filesystem. Not sure if this is possible though to get the git hash information in C?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I refer to the git commit information often when debugging (while careful to not have GMT installed via conda), so I added this option to the GMT_Get_Default API function in GenericMappingTools/gmt#6493 so that we can keep this information in show_versions.

"padding": self.get_default("API_PAD"),
"binary dir": self.get_default("API_BINDIR"),
# API_BINDIR points to the directory of the Python interpreter
# "binary dir": self.get_default("API_BINDIR"),
"share dir": self.get_default("API_SHAREDIR"),
# This segfaults for some reason
# 'data dir': self.get_default("API_DATADIR"),
Expand All @@ -169,6 +170,9 @@ def info(self):
# "image layout": self.get_default("API_IMAGE_LAYOUT"),
"grid layout": self.get_default("API_GRID_LAYOUT"),
}
# API_BIN_VERSION is new in GMT 6.4.0.
if Version(self._info["version"]) >= Version("6.4.0"):
self._info["binary version"] = self.get_default("API_BIN_VERSION")
Comment on lines +174 to +175
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the binary version supposed to be just 6.4.0 (with no hash or date) for the official GMT 6.4 conda-forge package added in conda-forge/gmt-feedstock#212? I was expecting a string like 6.4.0_434ed18_2022.03.11, but am getting this output from python -c 'import pygmt; pygmt.show_versions()'

PyGMT information:
  version: v0.7.1.dev92+gde7026137
System information:
  python: 3.10.5 | packaged by conda-forge | (main, Jun 14 2022, 07:04:59) [GCC 10.3.0]
  executable: /home/username/mambaforge/envs/pygmt/bin/python
  machine: Linux-5.17.0-1016-oem-x86_64-with-glibc2.35
Dependency information:
  numpy: 1.23.2
  pandas: 1.4.3
  xarray: 2022.6.0
  netCDF4: 1.6.0
  packaging: 21.3
  geopandas: 0.11.1
  ghostscript: 9.54.0
GMT library information:
  binary version: 6.4.0
  cores: 12
  grid layout: rows
  library path: /home/username/mambaforge/envs/pygmt/lib/libgmt.so
  padding: 2
  plugin dir: /home/username/mambaforge/envs/pygmt/lib/gmt/plugins
  share dir: /home/username/mambaforge/envs/pygmt/share/gmt
  version: 6.4.0

and output of mamba list | grep gmt is:

dcw-gmt                   2.1.1                ha770c72_0    conda-forge
gmt                       6.4.0                h78e8b95_2    conda-forge
gshhg-gmt                 2.3.7             ha770c72_1003    conda-forge
pygmt                     0.7.1.dev92+gde7026137          pypi_0    pypi

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the binary version supposed to be just 6.4.0 (with no hash or date) for the official GMT 6.4 conda-forge package added in conda-forge/gmt-feedstock#212? I was expecting a string like 6.4.0_434ed18_2022.03.11.

For official releases, the version string is 6.4.0 without hash and date. 6.4.0_434ed18_2022.03.11 is the version string for dev versions.

return self._info

def __enter__(self):
Expand Down
12 changes: 9 additions & 3 deletions pygmt/tests/test_clib.py
Original file line number Diff line number Diff line change
Expand Up @@ -873,16 +873,22 @@ def mock_defaults(api, name, value): # pylint: disable=unused-argument
"""
Put 'bla' in the value buffer.
"""
value.value = b"bla"
if name == b"API_VERSION":
value.value = b"1.2.3"
else:
value.value = b"bla"
return 0

ses = clib.Session()
ses.create("test-session")
with mock(ses, "GMT_Get_Default", mock_func=mock_defaults):
# Check for an empty dictionary
assert ses.info
for value in ses.info.values():
assert value == "bla"
for key, value in ses.info.items():
if key == "version":
assert value == "1.2.3"
else:
assert value == "bla"
Comment on lines +876 to +891
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there also be a mock for if name == b"API_BIN_VERSION" and if key == "binary_version"? Or would that break with #2079?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At line 173 in pygmt/clib/session.py, we have the following code:

            if Version(self._info["version"]) >= Version("6.4.0"):
                self._info["binary version"] = self.get_default("API_BIN_VERSION")

The Version() class requires self._info["version"] being a valid version string, so we can't give a value like bla to API_VERSION.

There is no such problem for API_BIN_VERSION, so no special operation is done for it.

ses.destroy()


Expand Down