search

sate-dev / sate-core

3 stars 3 forks source link

Assuming "mafft" is a python script #4

Open smirarab opened 13 years ago

smirarab commented 13 years ago

a nice feature of SATe is that you can substitute the default bundled tools with whatever version of the tool you have available by changing the path attribute in config files. This however, does not work for mafft. The real mafft program is not in python. In SATe there is a python script that wraps around mafft. But it is hardcoded in SATe that mafft should be called with "python". Now if I change my local path to a real mafft installation, it will fail because mafft is not in python (it's a shell script). 

Exception: SATe failed because one of the programs it tried to run failed.
The invocation that failed was: 
    "/lusr/bin/python" "/projects/sate7/tools/bin/mafft.6.857-64bit" "--localpair" "--maxiterate" "1000" "--ep" "0.123" "--quiet" "XXX.fasta"

  File "/projects/sate7/tools/bin/mafft.6.857-64bit", line 5
    myself=`dirname "$0"`/`basename "$0"`; export myself
                       ^
SyntaxError: invalid syntax

If we were dealing with linux we could have solved this with a simple shebang. But I don't think windows works with shebang. Instead I think we need to create a small platform-dependent script (Shell, .bat, etc.) that calls the python script. This way we don't need to hard-code python in tools.py and therefore user can customize mafft to use a real installation on their systems.

mtholder commented 12 years ago

I agree that assuming python is a bit ugly. But I'm not sure how difficult it will be to get the .bat file executed from the GUI-invocation on Windows. I'm willing to look into this again, but I'm hesitant to risk breaking the Windows build.

A workaround would be to write a simple (2-3 line) python script that invokes the real mafft will all of the arguments (rather than our homegrown mafft python script which is more limited in terms of the number of options that it supports)

smirarab commented 12 years ago

Yes, that workaround should work. I know little about windows invocations too. I was hoping .bat invocation in windows is similar to any other invocation, but I am not sure about that. This is not a big issue in any case. Another simple workaround for Linux users is to simply remove the python call from the code (that is what I am doing).