-
Notifications
You must be signed in to change notification settings - Fork 235
pygmt.show_versions: Show GMT binary version and hide the Python interpreter path #1838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Here is the output when When |
| """ | ||
| if not hasattr(self, "_info"): | ||
| self._info = { # pylint: disable=attribute-defined-outside-init | ||
| "version": self.get_default("API_VERSION"), |
There was a problem hiding this comment.
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.11is obtained by callinggmt --version. However, when multiple GMT versions are installed, the commandgmtand the librarylibgmtmay 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 thegmt: 6.4.0_434ed18_2022.03.11information.
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?
There was a problem hiding this comment.
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:
- The GMT version information
gmt: 6.4.0_434ed18_2022.03.11is obtained by callinggmt --version. However, when multiple GMT versions are installed, the commandgmtand the librarylibgmtmay 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 thegmt: 6.4.0_434ed18_2022.03.11information.So we will only have
6.4.0printed out. This is ok for most users who install the offficial release versions, but for those who install thedevversions, 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.0and6.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?
There was a problem hiding this comment.
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.11from 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 string6.4.0_434ed18_2022.03.11through 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?
There was a problem hiding this comment.
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.
c8f7282 to
3dfae7b
Compare
|
I've updated this PR to show the GMT version from the API parameter |
|
We need to make it backward compatible with the old GMT versions if we decide to |
|
I've made the commit 8df1b55 to make sure the new Here are the outputs for different cases: GMT 6.3.0 with geopandasGMT 6.3.0 without geopandasGMT 6.5.0 (dev) with geopandasGMT 6.5.0 (dev) without geopandas |
| if Version(self._info["version"]) >= Version("6.4.0"): | ||
| self._info["binary version"] = self.get_default("API_BIN_VERSION") |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 like6.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.
| 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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Description of proposed changes
API_BIN_VERSION.gmt --versionFixes #1830.