Closed MarkWieczorek closed 4 years ago
Hi @MarkWieczorek, as mentioned in #365, this is an upstream issue with GMT6.0.0. You'll have to wait for 6.1.0 to be released, or build GMT from the master branch and tie that to pygmt. Alternatively, you might be able to use pygmt.config
in your script to override your main gmt.conf file?
Alternatively, you might be able to use
pygmt.config
in your script to override your main gmt.conf file?
What PyGMT can do is always calling "gmt set GMT_COMPATIBILITY 6" when a session is started, i.e., adding
lib.call_module("set", "GMT_COMPATIBILITY 6")
after line 17: https://github.com/GenericMappingTools/pygmt/blob/c1f736adaa0afb999bf1c6add569fa8d0f21affa/pygmt/session_management.py#L7-L17.
What PyGMT can do is always calling "gmt set GMT_COMPATIBILITY 6" when a session is started, i.e., adding
lib.call_module("set", "GMT_COMPATIBILITY 6")
Smart, I can whip a pull request for that (or review one). Could make it into a bugfix release too.
But just a question (since I don't use gmt.conf files much), isn't it possible to set a local gmt.conf
file (see https://docs.generic-mapping-tools.org/latest/cookbook/features.html?highlight=gmt%20conf#overview-and-the-gmt-conf-file) to override the main gmt.conf
file in /home/.gmt
?
But just a question (since I don't use gmt.conf files much), isn't it possible to set a local
gmt.conf
file (see https://docs.generic-mapping-tools.org/latest/cookbook/features.html?highlight=gmt%20conf#overview-and-the-gmt-conf-file) to override the maingmt.conf
file in/home/.gmt
?
Yes, if you have a "gmt.conf" file in your current directory (where you run "gmt begin" or "import pygmt"), the local "gmt.conf" will be found and loaded as the "current" settings.
Running "gmt begin" (in CLI) or "import pygmt" (in PyGMT) creates a new GMT session. If you have a "gmt.conf" file in your current directory, ~/.gmt/gmt.conf
or ~/gmt.conf
, then it will copy the "gmt.conf" to the current session directory.
Sorry for being impatient. There were a couple post 6.0.0 gmt releases on brew (macos), and I just assumed that these would have included the prior gmt bug fixes.
No worries, it's still a valid concern. We're thinking of pinning to GMT 6.1.0 (when that gets released) for PyGMT v0.2.0, so things will get properly fixed by then.
That might take a while though, so I'll get the workaround PR done, and see if we can get it to you sooner for v0.1.1 :)
lib.call_module("set", "GMT_COMPATIBILITY 6")
Ok, we'll also need reset the GMT_COMPATIBILITY to the global default set in gmt.conf
when we exit pygmt (but can't figure out how to...). I think that's what the actual error mentioned in the OP is about.
Ok, we'll also need reset the GMT_COMPATIBILITY to the global default set in
gmt.conf
when we exit pygmt.
No need to do that. import pygmt
will create a separate session directory. If any global gmt.conf file is found, it will be copied to the session directory, then
lib.call_module("set", "GMT_COMPATIBILITY 6")
only changes the value in the session gmt.conf file. When we exit pygmt, the session directory will be removed, and the global "gmt.conf" keeps untouched.
pygmt continues to provide annoying errors about GMT_COMPATIBILITY. These can arise in many circumstances (such as in jupyter notebooks), but here is the easiest one:
OS: macos pygmt: v0.1 (installed via pypi) gmt: installed by brew (v. 6.0.0_5) python: 3.7.7