[Biopython-dev] Abstract application wrapper

[Davide Marchignoli]

Hi,

On Wed, 1 Aug 2001, Brad Chapman wrote:

> Hi Davide;
>
> As I mentioned above, it is really Jeff's call about whether or not
> he'd like to see something like this in blastall() and friends; but I
> do think having a general interface would be nice. There was a lot of
> talk as BOSC/ISMB conference this year about other programs that it
> would nice for biopython to interface to (EMBOSS in particular) so
> there is definately interest and a lot of work that could be done
> along these lines, if you are interested.
>
> Also, during one of the talks at the ISMB conference I got inspired
> and had an idea for a generic class for running Applications. Based on
> what I scrawled on a piece of notebook paper during the talk, I wrote
> up something that kind of sketches out the ideas I had and attached it
> to this mail. This isn't working code or anything -- just enough to
> show the ideas. I'm not really sure if this is good, but I thought you
> might be interested in looking at it if you want to work further on
> this. Feel free to use it or not use it.
>
> Thanks again for the patches and interest!
>
> Brad
>

I think it is really very nice!

In my opinion it is general enough to encapsulate most (if not all)
external programs used within biopython.

If there is an agreement on the interface I think it should not be a
problem to fix the implementation details.

However I slightly prefer the lighter version in which you have a class

AbstractApplicationCommandLine (yes to be shortened) instead of
AbstractApplication

where the only difference is that you do not have a run method and have
also a __str__ method behaving as construct_commandline. (or maybe better
something returning a list of strings?)

In my opinion the advantage of such architecture is that you do not have a
wrapper around the function running the application, but rather your class
works side by side with the function running the application.

You retain the lowest level interface given by the function to which you
can pass the os.system string and also an higher level interface in which
you pass an instance of some class derived from AbstractApplicationCommandLine.

In my opinion, at the moment the interface provided by blastpgp is not
completely low level. For instance you cannot pass to blastpgp a parameter
that is not listed in att2param. The blastpgp function already does some
kind of parsing. With this approach you would not repeat work (parameter
parsing would be done only at the level of the CommandLine class), you
would retain an interface at lower level than the one you have now and
finally you would have an high level interface provided by the
AbstractApplicationCommandLine class.

One of the nice things it would allow would be the following:

# NON working code, for example purpose only
def blastpgp(commandline):
  args = str(commandline).split()

  ...

  r, w, e = popen2.popen3(args)
  if commandline isinstance(BlastpgpCommandline) and commandline.streaminput:
    commandline.write_input(w)
  else:
    w.close

where BlastpgpCommandline implements:

def set_seqinput(self, seq_record):
  self.input_seq_record = seq_record
  self.streaminput = 1

def set_streaminput(self, stream):
  self.input_stream = stream
  self.streaminput = 1

def write_input(self, outstream):
  if self.input_stream:
    outstream.write(self.input_stream.read())
  elif self.input_seq_record:
    SeqIO.Fasta.FastaWriter(outstream).write(self.input_seq_record)
  else:
    raise ValueError

so the user could write something like

args = BlastpgpCommandline(...)
args.set_input(seqrecord) # passing a SeqRecord as input
align = blastpgp(args)


Let me know what you think about it.

Bye,
				Davide Marchignoli