[Bioperl-l] RFC: Bio::App::SELEX::RNAmotifAnalysis

[Fields, Christopher J]

On Aug 24, 2012, at 9:21 AM, Alexey Morozov <alexeymorozov1991 at gmail.com> wrote:

> 2012/8/24 Leon Timmermans <l.m.timmermans at students.uu.nl>
> 
>> On Thu, Aug 23, 2012 at 12:12 AM, Bottoms, Christopher A
>> <BottomsC at missouri.edu> wrote:
>>> I developed this application for a research lab here at the University
>> of Missouri. I was wondering if this sounded okay and if it were okay to
>> use the "Bio" namespace.
>> 
>> ...
>> Installing locally is usually a good idea, I recommend local::lib in
>> particular. This «overwriting core Perl modules» suggests to me you're
>> doing something wrong anyway though.
>> 
>> Leon
>> 
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>> 
> 
> So one is free to do whatever he pleases and call it Bio::MyAwesomeStuff,
> right? What is required to get to official bioperl distribution? I think
> some of my code might eventially prove useful.
> 
> Alexey Morozov
> LIN SB RAS
> Irkutsk, Russia


Alexey,

Any ideas on the name?  We (BioPerl) don't technically own the primary Bio:: namespace, but we do have substantial real estate there :) Confusing namespaces are my only concern.

Chris, 

Personally, using Bio::App doesn't seem right, mainly for the same reasons that Leon mentioned already, but if the modules are the basis for an application then I think the namespace makes sense (see the App::* namespace, for instance App::cpanminus/cpanm, App::perlbrew/perlbrew, etc).

Everyone,

It is a good practice to ask opinions on module names here and where they should go, though.  Doing so here is completely acceptable. (well, Bio* specific ones...)

My thoughts:

There are a number of CPAN Bio::* modules that don't use BioPerl, and I wouldn't want to discourage anyone from submitting code to something like Bio::Foo as long as the dependencies are noted.  I really want to remove the artificial barrier to CPAN submission for any Bio*-related Perl code, where the BioPerl devs must bless a set of modules prior to submission; it slows down development on your code as well as BioPerl in general.  I do highly suggest naming your modules in a way so they wouldn't be confused with BioPerl if possible, though, e.g. don't name something in a more specific namespace that BioPerl already occupies, such as Bio::Seq::MySeqFile, but feel free to ask if there are questions on this.

Re: what to do with modules: please submit the modules/distributions independently to CPAN.  I *DON'T* suggest asking us to include code within the main BioPerl distribution, unless it is something integral to the entire BioPerl distribution (e.g. core-like).  The reasons are two-fold.

First, CPAN is an integral part of Perl, and interactions and submission of code to it should be part of the learning curve (just as creating eggs for python or gems for ruby are parts of their respective communities).  It's very easy to add BioPerl as a dependency and submit a module on one's own:

    https://metacpan.org/release/Bio-EUtilities
    https://metacpan.org/release/Bio-Tools-Primer3Redux

There are lots of tutorials for doing so, and if you have multiple modules or plan on maintaining support I highly suggest looking into some of the modern approaches to distribution and release management, Dist::Zilla being the primary one.  BTW, the nice side benefits of submitting to CPAN: you get basic issue tracking and cross-platform testing for free (RT, CPAN Reporters), and it's easy enough to support.

Second, we have been bitten many times in the past with code that was added to the core distribution (BioPerl).  These are generally cases where code was supposed to be supported by the submitting authors, but for one reason or another they disappear, and the rest of the Bioperl developers may be left 'holding the bag' so to speak.  We can't easily maintain code we don't write, particularly with various coding styles, practices, etc (bioperl-live/run have around ~1000 modules).  Submission to CPAN places the maintenance responsibility back where it should be, on the submitting author.  

Frankly, beyond any namespace issues, wouldn't you want the ability/freedom to do with your code what you want?

chris