I’ve encountered a problem while running the act_anat_prepare_fsl script. I have a script which uses this command as part of a processing pipeline.
I get this error:
Traceback (most recent call last):
File "./act_anat_prepare_fsl", line 10, in <module>
import lib.app
File "/data/lren/program/ms_mrtrix/mrtrix3_msStandalone/scripts/lib/app.py", line 28, in <module>
import argparse
ImportError: No module named argparse
However act_anat_prepare_fsl works when I run it directly from the terminal. Both the terminal and the script use python 2.6.6:
python -c "import sys; print (sys.version)"
2.6.6 (r266:84292, Nov 22 2013, 12:16:22)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
In the terminal I also get this:
python -c "import argparse; print argparse"
<module 'argparse' from '/usr/lib/python2.6/site-packages/argparse-1.4.0-py2.6.egg/argparse.pyc'>
I think that for some reason the module is loading correctly when run from the terminal but not when embedded in my script. This is odd because I’ve used this many times without problems. Perhaps my administrators have changed something…
Do you have any idea how to fix the module loading? Or to debug the problem?
… Well, looks like you’ve managed to stump everybody with this one!
I can’t say I’ve seen anything like this myself. But I’ll lay down a couple of ideas in case it spawns something.
Are you absolutely sure that the act_anat_prepare_fsl script is invoking precisely the same version of Python 2? That depends on the result of the #!/usr/bin/env python line at the top of the file, which selects the first binary in your PATH called ‘python’.
What mechanism are you using to invoke this script within your own? Is it just a bash script? Or are you using something like Python’s os.system()? It’s possible that e.g. the latter may not read from the same configuration files during shell initialisation.
Have you tried installing an up-to-date masterMRtrix3 branch and invoking 5ttgen fsl? If for some reason that works, but your current version still does not, it might give you some contrast to look for where the issue is arising.
With Python’s versioning and 2/3 conflicts, there can be different meta / wrapper packages on different distribution package managers. It’d be worth checking with the admins to see if they’ve switched something here, or if something has changed in the underlying distribution.