[Biopython-dev] ApplicationResult and generic_run obsolete?
biopython at maubp.freeserve.co.uk
Tue Jul 7 22:49:27 UTC 2009
>> My vote is to document using subprocess and avoid creating our own
>> wrapper. No one has to learn a Biopython specific API for running
>> programs, and subprocess provides plenty of flexibility to get stdout,
>> stderr and return codes. For places where we feel like using subprocess
>> is tricky, additional documentation within Biopython should help those
>> encountering it for the first time. This gives us more time to work
>> on biology problems, and leaves the running programs problems up to
>> the greater Python community.
> Exactly. I'm sure there will still be questions on the mailing list from
> people about using subprocess, but if our documentation is done
> well enough this shouldn't be too much of a burden.
> That seems unanimous so far: Deprecate Bio.Application.generic_run,
> and document using subprocess instead. Good :)
I started trying to rewrite the tutorial sections using generic_run, and
unfortunately it looks like a reasonably cross platform replacement for
generic_run when all you want is the return code but you don't want
the tool's output printed on screen becomes quite complex, e.g.
return_code = subprocess.call(str(cline),
We need to use pipes for stdout (and stderr) to stop the tool's output
being printed to screen. Just using os.system(str(cline)) has the same
We needed to include the stdin as a pipe as a work around for a Windows
specific bug in subprocess if called from a GUI using Biopython, see
http://bugs.python.org/issue1124861 and earlier mailing list posts.
This may not be worth worrying about for the documentation examples,
as its a corner case and has been fixed in recent versions of Python.
Finally, we need to use shell=True on Unix (but not Windows as I recall
from looking at the Bio.Application code) as we are giving the command
as a string (rather than a list of the tool and its arguments). Maybe we
can make the command line wrapper object more list like to make
subprocess happy without needing to create a string?
I'll try and test this on Windows, Mac and Linux tomorrow - but maybe
we will want to include a replacement for Bio.Application.generic_run
after all? (Would "simple_run", "run", or "call" be good names?)
More information about the Biopython-dev