[Bioperl-l] Bio:Tools::Primer3, Bio::Seq::PrimedSeq, and Bio::SeqFeature::Primer

[Jason Stajich]

On Tue, 25 Mar 2003, Rob Edwards wrote:

> Elia and others,
>
> I like the idea of splitting up running from parsing. At the moment
> Bio::Tools seems to contain a lot of parsers, and then some other things
> that don't really go together (notably
  Bio::Tools::CodonTable,
> Bio::Tools::SeqStats, Bio::Tools::SeqWords, Bio::Tools::Sigcleave,
> Bio::Tools::OddCodes, Bio::Tools::IUPAC, Bio::Tools::Gel,
> Bio::Tools::WWW, Bio::Tools::pSW, Bio::Tools::Alignment::Trim). Perhaps
> a Bio::Tools::Parse would complement a Bio::Tools::Run?

The evolution of the toolkit yes.  There Bio::Tools has been grab bag for
quite a while.  The should be partitioned off to a different directory
eventually but that breaks backwards compatability so we've not done this.
If we move things to Tools::Parse we have the same problem.

> I took a look at Bio::Tools::Run::WrapperBase, and as far as I can see
> at the moment a lot of this is not implemented (e.g. run(),
> program_name(), and program_dir(). Is someone working on this, or should
> I spend a little time messing around with it.

It is a base class - all the implemented runners are in the bioperl-run
CVS module which inherit from the WrapperBase object.  That is what those
methods aren't implemented.

>
> How do you see this handling different input requirements? Presumably
> Bio::Tools::Run::WrapperBase would just pass whatever it is fed without
> thinking about it. Most programs require stdin to be in their own
> format, and few seem to be consistent (consider clustalw input versus
> phylip packages input versus primer3 input). I don't think that
> WrapperBase should handle these, rather the individual run modules
> should check the sanity of the input.
>

Check out what we've already done in bioperl-run - the Pise stuff in there
is a separate case and isn't for running analyses of local applications.

We have chosen to write a specific wrapper for each application.  The only
exception is for running the tools in EMBOSS since it has a grammar for
input arguments so we can verify that sensible parameters are provided.

> Rob
>
>
>
> On Fri, Mar 21, 2003 at 03:21:26PM +0800, Elia Stupka wrote:
> > Hi Robert,
> >
> > Good to see Primer3 coming along, some comments:
> >
> > you might want to have a look at bioperl-run. We have decided to split
> > the actual "running" of programs from their parsing, so in theory you
> > should have a Bio::Tools::Run::Primer3 that inherits from
> > Bio::Tools::Run::WrapperBase and has some standard methods such as run
> > (I notice you call the method exc, but the doc title is run...). Also
> > all the arguments can then be simply put in a begin block as arrays of
> > keyowrds which get "authorized" to be used by the OK_FIELD hash (see
> > any of the run modules in bioperl-run for more specs).
> >
> > Then the parser would go into Bio::Tools::Primer3 only for the parsing
> > methods, which would be at least the basic next_result method shared by
> > other Tool parsing modules (though admittedly we haven't yet come up
> > with a proper interface module or base class)
> >
> > Elia
> >
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>

--
Jason Stajich
Duke University
jason at cgt.mc.duke.edu