I have a Galaxy installation at a cluster that makes use of default python 2.7. I can see that there are 2 symlinks called python2 and python2.7 that maps to a python binary inside /galaxy/.venv/bin and calling it with --version returns
2.7.14
I recently installed a tool using tool.xml that has the following directive:
<configfiles>
<inputs name="inputJSON" filename="myConfig.json" data_style="paths"></inputs>
<configfiles>
The above directive tells galaxy to parse the entire UI from XML and create a JSON representation of the user choices, which is then passed to a perl script.
When I ran the tool I got the following error:
ImportError: No module named xml.dom.minidom
Since the tool and the wrappers are written in node and perl, I am guessing this has something to do with galaxy dependencies that is required to parse the xml directive above.
I checked the default python from $PATH and it's version is 2.7.14 as well. When I go to /usr/lib64/python2.7 or /usr/lib64/python I can see that there is a folder structure xml -> dom -> minidom.py. So it means I already have this module installed.
Next I went to galaxy/.venv and I see there is a folder called lib and another called lib64 which points to lib itself. Inside the lib there are many python scripts that are symlinks inside /usr/lib64/python2.7/. For example types.py maps to /usr/lib64/python2.7/types.py .
At this point I have 2 questions:
- Shall I create a folder symlink called
xmlinsidegalaxy/.venv/libthat maps to/usr/lib64/python2.7/xml? Would that be sufficient ? - Shouldn't these dependency symlinks be refreshed when galaxy is restarted? Because when I restart galaxy, I still get the same error, meaning galaxy is still not aware that this module exists.