https://bugs.kde.org/show_bug.cgi?id=405437
--- Comment #174 from Rob <rlanca...@gmail.com> --- I did some experiments last night with the issue you reported in a virtual machine with python3 installed in different ways to see why python3 sometimes is not working properly with astrometry.net to plate solve. Another user, who also installed non-homebrew python3 has reported a similar issue in this forum: https://indilib.org/forum/general/6362-kstars-mac-dmg-3-4-0-beta-testing-needed.html?start=72#48945 , and we were trying to diagnose it there too. In both cases, we did a number of experiments but couldn't find the problem. I decided to try a different approach. It was much easier for me to diagnose the issue in a virtual machine. I will post what I found last night in both places. The problem: The issue happens when the user has installed non-homebrew python. Python3 is installed properly, the site packages include astropy and numpy, it can find the site packages, the correct python3 is first in the PATH variable, KStars is installed correctly, and NOTE this is not the "illegal argument exception" caused by running software compiled for a newer computer on an older computer. But when the plate solve is run, it gives an error message which means it can't find astropy. When run from the command line, it gives the same error! My finding: It seems to me that the issue is that the calls to python astrometry.net are making use the name python not python3 when the calls are made. OS X has a python2.7 installed by default that is used by the system and should not be changed. Python3 is installed in various ways and could be in different locations. All the different python versions that I tested last night put a simlink in /usr/local/bin for python3 to redirect calls for python3 to wherever python3 is installed. There is not a simlink to python put in that location because the assumption is that if you call python, you want python2.7 to run the code and if you call python3, you want your self installed python to run it. I ran into this issue before with the homebrew python, and it gave me big headaches before, but later I found that there was a folder homebrew made called /usr/local/opt/python/libexec/bin where there actually was a simlink placed from python to the homebrew python3 and if I put that in the path, it automatically fixed the problem! I had assumed that the other versions of python would have a similar folder and you could just put them in the PATH variable and it would work. I was surprised last night when I didn't find a python simlink in /Library/Frameworks/Python.framework/Versions/3.7/bin (or similar folder for other installation), nor did I find anything in /Library/Frameworks/Python.framework/Versions/3.7/opt. So thus even with that folder in the PATH, it still called the system python whenever python was called for. Now that I think I know what the problem is, I should be able to come up with a way to fix it for non homebrew pythons. Just to verify, can you check for symlinks to python (not python3) in your /usr/local/bin folder, your /usr/local/opt/python/libexec/bin folder, and in whichever python3 bin and opt folder you would currently like to use (for example: /Library/Frameworks/Python.framework/Versions/3.7/bin and /Library/Frameworks/Python.framework/Versions/3.7/opt). If none of those folders contain a file or simlink called python, I think we have found the python3 issue. -- You are receiving this mail because: You are watching all bug changes.
