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
xml
insidegalaxy/.venv/lib
that 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.