After installing Miniconda3, adjust sys.path and os.environ, when loading import pygmt I get:
DistributionNotFound: The ‘pygmt’ distribution was not found and is required by the application
I can see the whole package on /usr/local/lib/python3.7/site-packages/pygmt and my sys.path shows /usr/local/lib/python3.7/site-package correctly.
Hi @andrebelem, we are aware that the Colab example hasn’t been working for a few months now. See https://github.com/GenericMappingTools/try-gmt/issues/17 and Installing PyGMT on Google Colab (oh wait, I just realized you were the one who posted the error). I did try to debug this last week when GMT 6.2.0 came out by trying different Python versions and so on but couldn’t get things to work either!
In the meantime, I’d suggest using the Pangeo binder links instead if possible. If you do manage to get things to work on collab, we’d be glad if you can share the solution with us!
Hi @weiji14.
It’s really weird because miniconda3 is correctly installed, as is python3.8 (so much so that I can start any command without any problems). I did a quick debug here and the problem shows up in the transaction between pkg_resources and _init.py (which is originally from python 3.7 !). Specifically the error is when init tries get_distribution(“pygmt”).version and gets scrambled between site-packages (3.8) and dist-packages (3.7).
Essentially this is a problem of running 2 versions of python on the same machine, and I’m trying to solve with other recipes for similar problems.
An important detail - my insistence on collab is that many of my students are just starting out in python and some have terrible computers. So the practical teaching solution is colab, for the convenience of them being able to run GMT examples without worrying about learning a lot of python. Pangeo is also very good! but I haven’t tested my class notebooks enough for an assessment. I am doing this now.
If I get a solution, I’ll post it here. Let’s leave the ticket open then.
Just an ugdate: I did a slightly different test this time:
(1) miniconda installed
(2) !conda install gmt -c conda-forge -y (to gmt source)
(3) !conda install pygmt --channel conda-forge -y (for pygmt)
Just in case, a “!find /usr/local/lib | grep pygmt” shows pygmt correctly in /usr/local/lib/python3.8/site-packages. Just to be sure again, I did “imports;
sys.path.append(’/usr/local/lib/python3.8/site-packages/pygmt’)”. All good.
!gmt --version shows correctly the gmt installed
To test in pygmt core, I used:
“os.chdir(”/usr/local/lib/python3.8/site-packages/pygmt")
from init import *"
The error is definitely in init.py where version = f’v{get_distribution(“pygmt”).version}’ returns a “dist” equal to “none” because it uses pkg_resources/init.py from python3.7. Even giving a symbolic link between the two repositories (3.7 and 3.8), the pygmt module cannot move forward because there is a “dist” restriction on init.py.
On the other hand, I tested another option which was to install gmt on colab (with a normal sudo apt install), and a simple “pip install pygmt” after… all good “but” - there is still no gmt6 version for apt installation and with that pygmt (which requires gmt6) does not work! The solution would be to compile from scratch inside collab but this extrapolates the “easy” flag I’m looking for my students.
Anyway, it is necessary to wait for the thing to evolve (or the colab or the gmt) so that they can talk OR we forget all this and each one lives in their “own little world”.
Just a detail answering why I’m so focused on colab and GMT: a map in lambert conic projection at high latitudes, “only and exclusively” in GMT is what is presentable. Python’s other competing solutions are horrible. Anyway, I’m just letting off steam.
At some point and with more time I will continue with other alternatives.
Thanks for the detailed writeup! You’re right that there’s something to do with the different Python versions (3.7 and 3.8), and I can totally understand your frustration. Not to get your hopes up, but have you tried conda install gmt followed by pip install pygmt? I haven’t tested it myself but wonder if this might be a possible workaround.
Another thing you raised is that colab may have a problem with Python’s setuptools-scm used by PyGMT. That get_distribution("pygmt").version chunk of code was added in https://github.com/GenericMappingTools/pygmt/pull/695 in Nov 2020, and could be one reason why things are failing. Not easy for us to revert to non-setuptools-scm though, or debug this on colab (so I’m hoping this isn’t the actual problem).
Hello @weiji14,
yes. I tested conda install gmt followed by pip install pygmt. In fact, I was able to install everything using the python 3.7 version but the best approach was to install gmt using apt-get and THEN pip install pygmt. However, the problem then is with gmt5 version (via apt) and missing important blocks in pygmt, which crashes.
if I got it right, via apt install only gmt5 is possible for colab and pygmt needs gmt6.
The solution that seems the most viable and simple to me is (1) to create a repository for the precompiled gmt6 version, (2) install via apt, then (3) pip install pygmt and (4) correctly point out where the libraries are. I’m looking at how to create a repository to make it easier for my students to install. (I haven’t given up yet).
Cheers
PS: I studied what you told me and setuptools_scm is really an excellent tool. I looked for some alternatives on how to use it with different versions of python co-installed but that’s exactly what it prevents. So changing this is not the correct way (but detail: pygmt is correctly installed on python 3.8 but somehow it asks for python 3.7 settings and breaks).
I’ve tried a few things today (including focal fossa’s GMT6.1.0 and Hisrut’s GMT6.1.1) but really a lot of packages get broken, mainly in the link to system dynamic libraries in addition to gmt. It’s really not a good strategy. The farther away from the base of the Bionic 18.04, the worse it gets.
Today I tried to reduce the problem to the focal with: !sudo add-apt-repository "deb http://ubuntu.mirrors.tds.net/ubuntu focal main universe" !sudo apt-get install libhdf5-103 !sudo apt-get install libnetcdf15 !sudo apt install gmt
This strategy worked and gmt6 was correctly installed, but conflicts appear with several python libraries and it was also a dead end, especially considering that the whole process takes 5 full minutes. If you wait 5, you can wait 8 minutes for the “build from scracht” solution.
I think at some point google will update the VM to 20.04 which is also an LTS version. We can only wait. Meanwhile, the solution I put on github works, and today was the exact time to (1) run it, (2) go to the kitchen to prepare coffee and (3) come back (8 minutes sharp).
This week I’m going to pass this recipe on to some student “newbies on colab” and see how they react with just a few instructions. If there are no major problems, this is the simplest solution, especially since it installs everything and compiles without asking the user anything - which is desirable in these cases.
@andrebelem thanks for sharing the solution. I am new on this, but running the code I got a warning message: WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
So PyGMT couldn’t be installed in my case, should I try in a venv ?