I am trying to configure snappy (using SNAP version 7) on my computer (Linux, fedora), having it connected to anaconda python 3 .
Following is what is written in the file snappyutil.log
INFO: Installing from Java module ‘/home/egr/snap/snap/modules/org-esa-snap-snap-python.jar’
WARNING: Architecture requirement possibly not met: Python is x86_64 but JVM requires amd64
INFO: Installing jpy…
ERROR: Traceback (most recent call last):
File “./snappyutil.py”, line 280, in _main
File “./snappyutil.py”, line 154, in _configure_snappy
" $ cd jpy"
AttributeError: ‘list’ object has no attribute ‘join’
Look at the block in snappyutil.py ending at line 154. You will see that the “join” error prevents you from seeing an error message. You will also see that the above version has fixed the “join” error, so you may have missed an update.
The bug prevented you from seeing a message that snappyutil.py can’t find a jpy that matches your python version. Configure Python to use the SNAP-Python (snappy) interface lists the supported python versions. I see you have installed Anaconda Python, but you didn’t mention the version. When you have multiple python versions it can sometimes be tricky to ensure that snappy uses the appropriate version. There are several ways to specify which python is used to run a script. On linux you can put the path to the Python program in the first line of each script, and use the “USERPROFILE” method from the above “Configure Python” link to use sys.path.append(snappy_dir). Note that for linux you need to replace “USERPROFILE” with “HOME”.
Just wanted to add to this that I am having the exact same issue. On windows64 bit with Python 3.7 and attempted with 2.7 to check if it was a python compatibility problem. Using the latest download of SNAP.
Besides the faulty logging code, the fundamental issue seems to be that jpy will not install on my system and/or connect to the snappy install.
I tried following these instructions:
and this troubleshooting:
But the final outcome is still a failure to install jpy in a way that resolves the connection/environment in a way that snappy can find it.
I have spent two days on this, adding java environment paths and installs. Apache installs with a maven specific jpy install (which seems to work, but snappy cannot find it nor my main python install). Manual install and build in the snappy folder of the jpy .whl and core code. Install C++ dev kit. Visual basic dev kit. Java dev kit. All to no effect.
I have now given up and hope that one-day the tools are re-written in pure python so that we can avoid java entirely!
Or someone has a guide to install on anaconda 3 with a recent Python 3 type that resolves these issues?
The GEO-ICT installation instructions look fine to me, but some users find it tricky to ensure that Python always uses the “snap” environment. Anaconda environments are very useful when you plan to install other tools available via conda, but if you don’t need those, Python 2.7 or 3.6 (the “active” releases from python.org) should be easier to manage.
Where did the GEO-ICT setup fail for you?
I’m sorry you lost so much time – unless you already use a JDK, Eclipse, maven, and C++ and have special requirements, it is much better to stick with a basic configuration that is widely used so others will be able to help with problems. Visual Studio brings in its own Python support but installs Python in the user’s Appdata folder with a long complicated path that makes it tricky to use with snappy. It is also best to use the same Java runtime for both SNAP and snappy so you don’t have to worry about Java differences when things don’t work as expected.
The above configuration instructions include a simple test to ensure the configuration is working, and offers several ways to ensure that python can find snappy. I recommend the “generic” method based on USERPROFILE because it works for any system that installed snappy when SNAP was installed, so make it easier to share Python scripts (the same method also works in linux using HOME instead of USERPROFILE). If you have multiple Python versions and try to install snappy into your desired Python installation, be careful to check it actually ends up in the right place.
Hey, no worries, and thanks for a quick reply. Of course, the classic thing happened as soon as I complain to someone… I managed to fix it. You are absolutely right that all those other JDK were causing more problems than they solved.
I have now managed to fix it by:
A complete uninstall of all those packages and SNAP.
Create a new clean conda environment with Python 3.5, making sure the conflicting snappy (a compression lib from google) is not present.
Re-install SNAP, pointing it towards the python.exe of the new environment.
Follow the GEO-ICT instructions.
Really was that simple! I think the core problem before was that Python 3.7 seems to be incompatible with snappy and/or jpy. By the time I had switched to v2.7 all those other steps I had taken were breaking things. Rolling it all back and then switching to 3.5 was enough to resolve. I have not tested with 3.6 as now have it working am loathed to change it heh.
Thanks for the user-profile advice as well. The end-use here is to develop a script on my local machine that will then run on a larger machine. So ensuring it works across multiple set-ups is essential.
I wonder if it is worth making a clear FAQ section that covers all of this sort of thing in the snappy-config wiki so that silly mistakes like mine are easier to catch? Suggested placement being here. As it was from here that I started to cause myself problems!