[Bioperl-l] updates, new code, invitation to contribute

[Jason Stajich]

Some updates and requests.

I'd appreciate if people could start to report in more summaries of 
what changes they have committed in addition to what we see in the 
bioperl-guts commit list it is useful to have a summary of what's going 
on from the authors.  In the interest of making the next release easy, 
please try and add something to the Changes file to describe any major 
additions to the API, squashed bug, or more than formatting changes.  I 
think we are probably going to need to do at least one or two more dev 
releases under the 1.5 series before we can think about a 1.6 so this 
log of changes will help us determine what will actually be new in a 
release.

===

Some updates from me.
Bio::Tools::Phylo::PAML
I just added RST parsing so one can parse ancestral sequences in as 
well as per site ancestral codon probabilities at each node in the 
tree. Last month I also added parsing of branch-specific parameters 
when those constraint models are applied in codeml/baseml.  You can get 
these values by walking up the tree and getting the tag/values 
associated with each internal node.  I've updated the SYNOPSIS to have 
more examples of these things and as well most things are also shown in 
the t/PAML.t tests.  I'm working on including these examples in the 
PAML HOWTO.

Bio::Factory::FTLocationFactory
  Hierarchical parsing works even for joins of joins now.  This is using 
a regexp solution which seems to be suitably fast but has the problem 
of not working on perls < 5.6.1.

scripts
  I fixed a bug in fastam9_to_table which allows it to parse TFASTX m9 
output properly now.

bioperl-run
I've tried to expand the cmd-line options that several tools support - 
Bio::Tools::Run::HMMER.  Better default option handling in 
Run::Phylo::PAML::Codeml

===

Bug fixing help!
There are a lot of bugs sitting in the bugzilla queue.  I realize it 
may not seem easy for someone to jump in and work on, but that is how 
you learn the toolkit (it's how I learned to do things on this 
project).  Even if you simply try out to see if the bug is reproducible 
that is helpful.   Right now feels like me and a few other folks 
against this massive wall of things to do and so we're probably only 
going to fix the things we are feeling particularly excited about.

So we need more volunteers to do things like take a look at these bugs. 
  We also need people to help read the documentation, synopsis, etc and 
report if it is inconsistent and (preferably) help us fix it.  I have 
encountered several new converts to Bioperl who are constantly stymied 
by not being able to get the Synopsis to work as they expected.  Of 
course these folks also feel to shy to email the list and tell us 
something is wrong, and then it never gets fixed....  So really, help 
out, let us know when something is wrong.  If you want to help out (and 
get your name in shiny ASCII code in the AUTHORS file) contribute a 
couple of fixes through bugzilla, if you are doing it right we'll give 
you an account and you start helping even faster.

===

Future stuff
Lots of people, and I mean, lots of people cannot seem to get bioperl 
installed.  Sometimes this is all I hear from newbies when I meet folks 
or teach a class.  I think this is really due mostly to the 
dependancies, and probably because people don't know how to use UNIX 
and/or understand where perl modules go.  But people building RPMs 
complain, the new OSX users, and of course windows users always seem to 
have a lot of trouble getting things working.  I think this is more due 
to the dependancies than Bioperl itsself.

I think it may be worth considering moving stuff that has lots of 
dependancies out of the main core code and into separate installable 
packages.  IO::String is not a large dependancy, but LWP starts to be 
add any of the XML modules, Graph, etc and it seems to be too large of 
a hurdle for many new folks.  Maybe anything which depends on code 
linked to an external C library would be a candidate.  I think more 
discussion is warranted for sure, this would not be an easy thing for 
us to undertake.  But in the end it would produce a slimmed down core 
set of pure-perl modules that would be easy to use out of the box.  The 
other alternative is to make a slimmed down bioperl-lite which is just 
and export and subset of bioperl modules which are pure-perl and have 
little or no dependancies...

This would make it easier for people who don't need all the extra bells 
and whistles.  I think it doesn't necessarily split by directory 
namespace however, for example SeqIO has some XML dependent modules 
which (under this proposal) get moved into a separate package.

===

At any rate, that is all food for thought and perhaps can be discussed 
by folks over the summer at the upcoming meetings and hackathons.

-jason

--
Jason Stajich
jason.stajich at duke.edu
http://www.duke.edu/~jes12/