[BioRuby] Proposal: Bioruby modules (the bazaar)

Toshiaki Katayama ktym at hgc.jp
Thu Jan 21 17:54:24 UTC 2010


Dear Pj,

I can understand your frustration and I like your idea of the
'module' system, as it reminds me the way how the Linux kernel
tree is successfully maintained.

> I wonder how many people on this list would contribute code if it was
> more loosely organised.

Indeed.

However, I think our move from cvs to git was already a great step
that it opened large opportunity to all those who want to participate
in development. Before doing that, "open source" project not always
mean "open to join" project.

Now, everyone can easily fork the project and release their modified
codes as you already done. So, we may able to evaluate from the current
situation that how many other people have tried.

Anyway, it is still a difficult problem that who will decide and
how to decide when to migrate the contributed code into the main tree.
It might sound like a excuse, but I'm also suffering from the difficulty.
I also have several modules which are not yet contributed to the main tree.
For example, my SGE library for BioRuby (http://kanehisa.hgc.jp/~k/sge/)
because I'm not sure it is general enough and where it fits.


As for the HTML portion, I see your point.

* I'd like to hear comments from others.
* How people like to render/visualize the BioRuby objects (especially in HTML)?
* I didn't mean to use the CGI class for HTML generation (I even don't like that).
* The use of <p /> seems invalid in XHTML. See http://www.w3.org/TR/xhtml1/#C_3


P.S.
Once, I had developed a mechanism to integrate end-user code snippets
in the BioRuby shell, called plugins. I wrote some plugins which render
a colored codon table, a formatted summary of sequence properties etc.

If those and functions defined in your plugins can be easily accessed by

  puts Bio.your_function_name(options)

or something like that, is it satisfy your needs?

If so, we can consider to make a repository for such plugins and bundle
them in the BioRuby as well.

Regards,
Toshiaki Katayama


On 2010/01/22, at 1:20, Pjotr Prins wrote:

> Dear Toshiaki,
> 
> On Thu, Jan 21, 2010 at 11:05:42PM +0900, Toshiaki Katayama wrote:
>> I looked your code and had a feeling that we should use some
>> template system.  If HTML tags are hard coded in the library as you
>> did, it will be very hard to modify them by the user.
> 
> Aren't we trying to overcomplicate things? This is an HTML generator
> - in fact it is embedded HTML as I don't provide the <html>, header or
> body parts. It can just be inserted into Rails, or whatever HTML
> framework that is out there.
> 
> Templating is just another abstraction. I don't intend to template
> engines like Rails.
> 
> Or, are you here merely referring to using the CGI class (or something
> like that).  I guess I could do that, though I have trouble seeing the
> benefits. It is just another way of writing HTML statements.
> 
>> Besides, what version of the HTML specification did you have in
>> mind?
>> This is my first time to see the <p> tag is used in the form of <p />. Is it valid?
> 
> Yes. It is, in fact, XHTML.
> 
>> I also think decorations should be separated to the CSS layer and you should avoid to use the <font> tag, especially when you are trying to distribute your code as a part of the library.
> 
> We use hard coded colors. I could use CSS, but then you need to
> provide a CSS file (or I need to hard code the header of the file).
> That makes it (again) more complicated than necessary. Where do we
> store the CSS file, how do we make sure the browser finds it? CSS is
> really to adapt look and feel. If the output is meant to be fixed, why
> make it flexible?  Besides all (future) browsers support the font tag,
> as used. If that stops we could always adapt that source code.
> 
>> As for the file location, I still like the way Naohisa has
>> suggested.
> 
> Alright. I can move the files, if that was all.
> 
> However, my colored alignment is not going to make it into Bioruby
> this way. There is always something wrong with my code, it appears.
> Now I need to move file locations that have not really been decided
> on; I need to template HTML - but we haven't decided how and it is
> questionable; I need to use CSS, though I think it makes things worse
> for users.
> 
> Are we really sure you want to reject this code just because it does
> not live up to everyone's current and future expectations? It may
> still be useful to someone else, you know, it does not break anything
> else, and can be improved in the future. Once we decide what we want
> to achieve.
> 
> The same really holds to my PAML branch and my GEO branch. Both
> contain useful utilities for others to use. And now the alignment is
> the third pending Bioruby branch.
> 
> Can you imagine my growing frustration? Should this go into Bioruby,
> or should I start another project, like others have done? Or stick it
> into my existing biotools or bigbio projects? Just, so I don't have
> the hassle?
> 
> The way the Perl people handle it is by having independent modules.
> Everyone owns his, or her, own module and Perl's CPAN acts more as an
> aggragator. The advantage is that the environment is more dynamic. And
> you really don't care what is inside a module. That is up to the
> maintainer and his/her users.
> 
> We could create independent BioRuby modules, which have their own git
> repositories. When a module is nice enough to include in Bioruby make
> it a git submodule - I use this technique for biolib - it will
> register in the BioRuby repository. That way Bioruby still controls
> what goes in a release. However, modules can be maintained for
> experimental setups or private use. So my modules would go in
> 
>  lib/bio/modules/paml
>  lib/bio/modules/geo
>  lib/bio/modules/htmlalignment
> 
> each its own git repository.
> 
> When one of those is 'strong' enough for main line you move it into a
> different location in the main repository. Modules could even be
> included in Bioruby releases.
> 
> What hurts me now is that no one is going to use my code, since I
> don't have the time to make it perfect, and it is hidden in my
> experimental Bioruby branches. We should find a way to make
> 'experimental code' available to the rest of the community. That way
> we may also 'recruit' help to make the code more perfect. 
> 
> Make it easy to allow external modules to become visible through
> Bioruby - that is a win-win, as well as a more bazaar-like approach
> to OSS development.
> 
> I wonder how many people on this list would contribute code if it was
> more loosely organised.
> 
> Pj.





More information about the BioRuby mailing list