[BioRuby] Bio::Assembly

[Chase Miller]

Pjtor

Thanks for the great ideas!  The BioLib project sounds interesting.  I'll
have to ask my old GSOC mentor Mark Jensen about it.

However, for my purposes, It may be easier to just code it up in ruby (also
I'm dying to write ruby code after moving over from perl :) ). What I need
is an ace parser and fairly simple scaffold and contig objects. Although
slim in features, it could be a good starting point for a pure ruby assembly
module, which I wouldn't mind maintaining.

How closely does BioRuby like to follow the BioPerl API?

I've noticed that BioRuby seems to handle file formats differently than
BioPerl, with most of them being in Bio::db/.  Can anyone expand on this?

Is there any place I can read about the best practices for BioRuby.  For
example, I haven't seen any instances of using hashes to pass parameters in
method calls e.g.


a.parse( :file => file, :format => format )

Is this frowned upon in BioRuby?


Thanks,
Chase


On Wed, Jul 7, 2010 at 1:46 PM, Pjotr Prins <pjotr.public14 at thebird.nl>wrote:

> On Wed, Jul 07, 2010 at 09:27:17AM -0700, Christian Zmasek wrote:
> > C/C++? Perl?? Really?
> >
> > Do you think it is a good idea to introduce so many dependencies?
>
> Not at the same time ;)
>
> > While these might not be a problem for expert users, I worry that
> > the to more complexities are introduced the less likely the avarage
> > biologist with little coding experience might be tempted to use
> > BioRuby.
>
> It won't affect BioRuby core.
>
> Pure Ruby is great - and we should always aim for that with 'core'
> BioRuby. Still, we don't have enough developers to support every nook
> and cranny of bioinformatics.
>
> We need to get functionality in fast, when we can. If functionality
> exists elsewhere: use that. It does not make sense to rewrite
> everything from scratch. As long as we provide clear interfaces, we
> can always start replacing stuff with pure Ruby. If someone feels
> like recoding.
>
> By forcing dependencies into a 'plugin' we still keep BioRuby pure.
> People are free to create plugins, which may have dependencies. If you
> want the functionality badly enough, and you don't want to write it
> yourself, find the way of using the plugin. This is one of the major
> reasons for providing a plugin infrastructure. Which, btw, is the
> same plugin system that Rails uses (thanks to Raoul and Toshiaki).
>
> A plugin is not core BioRuby. BioRuby itself does not get dependencies
> - other than highly common libraries like libxml.
>
> We simply don't have the people to achieve everything. Not to mention
> that many libraries, like EMBOSS, outperform Ruby in terms of
> processing speed and memory consumption. When we call BLAST we don't
> write BLAST ourselves in Ruby. Those are also dependencies.
>
> Outside dealing with dependencies one thing we may want to think about
> is incompatible plugins. For example, if I were to use a plugin
> for the JVM, it may not work together with a plugin for standard Ruby.
>
> My take is that it does not really matter. You have to choose one or
> the other ;).
>
> Truth is we have too small a community to provide the luxury edition
> of BioRuby which can handle everything (which is also true for the
> other Bio* projects).
>
> See mappings and dependencies as part of the development of the
> ultimate BioRuby. A process, transition, evolution. Plugins make it
> possible.
>
> Pj.
>