[BioRuby] Bio::Assembly

[Anthony Underwood]

Hi Chase

I for one would love to have a ruby implementation of a Bio::Assembly module. I wrote a Bio::Chromatogram module for bioruby to replicate the bioperl functionality since I can not stand writing in perl any longer!! I have thought about writing an ace parser also but have not yet had time.

Count this a +1 from me!

Anthony
On 8 Jul 2010, at 12:29, Chase Miller wrote:

> 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.
>> 
> _______________________________________________
> BioRuby Project - http://www.bioruby.org/
> BioRuby mailing list
> BioRuby at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioruby