[Biopython-dev] ApplicationResult and generic_run obsolete?

[Peter]

Brad wrote:
>> 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.

Peter wrote:
> 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.

import subprocess
return_code = subprocess.call(str(cline),
                              stdin=subprocess.PIPE,
                              stdout=subprocess.PIPE,
                              stderr=subprocess.PIPE,
                              shell=(sys.platform!="win32"))

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
problem.

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?)

Peter