pjotr.public14 at thebird.nl
Wed Jul 7 17:46:05 UTC 2010
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
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
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
More information about the BioRuby