[Bioperl-l] bioperl reorganization

[Chris Fields]

(Jay and Robert pretty much sum up what I think as well, so I won't  
attempt answering all of these)...

On Jul 17, 2009, at 5:49 PM, Jay Hannah wrote:

> Robert Buels wrote:
>> Once things are less monolithic, developing and releasing *should*  
>> be a LOT easier.  As Jay also mentioned a bit, it's more like on  
>> Tuesday Charlie notices a bug in Bio::Foo::Bar, fixes it.  Pushes  
>> it to CPAN (with a small version bump) immediately afterward.   
>> Users pick it up via Task::BioPerl.  That's it.
>
> Hmm... In the Catalyst model, users never get a new copy of  
> Bio::Foo::Bar unless they explicitly install it.
>
> Typically, a user is perfectly happy with their pretty-out-of-date  
> copy of Bio::Foo::Bar sitting on their server. It works for them, so  
> they don't care.
>
> The big difference for the typical user, I think, is that when they  
> go to install a new server, grabbing the list of things they care  
> about from CPAN, what they're getting is current up to TODAY,  
> instead of months/years old.
>
> Like I said, I'm a bioperl-live addict, so haven't cared about CPAN  
> being current. But I'm blindly guessing that 95% of our customers  
> install whatever is sitting on CPAN right now. (That's certainly how  
> the rest of the Perl universe works.) A shame that our customers  
> continually don't benefit from all the recent hard work.

Actually, I think the problem is, either we have a large set of users  
using bioperl-live as if it were stable code, or we have users using  
very old code (1.2.3  due to ensembl, and 1.4, yes, even after 1.6 was  
released).

Part of this an be blamed (I'm sorry to say) on ensembl's continued  
insistence that they are only compatible with bioperl 1.2.3. I would  
really like a concrete reason on exactly WHY bioperl after 1.2.3  
supposedly doesn't work with new Bio::EnsEMBL* code.  I have some  
current scripts that beg to differ, so it can't be that broken, and if  
it is, we can certainly work coordinately to fix it.  But requiring a  
certain part of our user community install an over 6-yr old version  
with a ton of bugs does not make me happy.

>> Or, how about a slightly longer case study:
>> Say on Wednesday Charlie notices that the design of Bio::Foo::Bar  
>> sucks and it really needs some work.  He codes furiously for  
>> however long it takes, makes Bio::Fooer::Bar or something like  
>> that, in a new distribution, and pushes it to CPAN.  Initially, no  
>> other modules are going to be using it, but then say Jason, the  
>> maintainer of Bio::SeqIO::fasta, notices that hey, Bio::Fooer::Bar  
>> is a lot better than Bio::Foo::Bar.  Then he can just use it, test  
>> his new Bio::SeqIO::fasta with it, put it in his dist's Build.PL as  
>> a dependency, and push to CPAN.  Now it's getting pulled in with  
>> Task::BioPerl and *USERS* now have been given that improvement,  
>> probably in only a matter of days.  There are automated tests at  
>> every step of the process to ensure quality throughout.
>
> Yup. Every dist can declare it's dependency stack with every  
> release. If Bio::Foo::Bar is abandoned by all distributions, a new  
> copy of that dist is flagged DEPRECATED ("in favor of  
> Bio::Fooer::Bar"), and pushed to CPAN. That clues everyone in that  
> development has stopped and where they should go instead. For example:
>
>  http://search.cpan.org/~mramberg/Catalyst-Plugin-FormValidator-0.03/

Okay, but seems kinda crufty.  I do think there is some talk of  
removing such modules from the active CPAN, as they would always be  
available as part of BackPAN, but I haven't seen movement along those  
lines.

>> Or for larger changes, coordination among several distros may be  
>> necessary, but the nice thing is, exactly which ones those are is  
>> codified in all their Build.PL files!  Much less guessing and  
>> worrying about unintended consequences.  Things are abstracted into  
>> smaller chunks, which are much easier for developers to wrap their  
>> minds around, which means developing is easier, which leads to more  
>> contributors and accelerated development.
>
> Ya. Two years ago there's no way I would have dared to change  
> Catalyst. But changing Catalyst::Foo::Bar::Baz was far less  
> intimidating and I was happy to submit a patch. That's how they  
> hooked me, and they've had me ever since. Then Moose got me, the  
> exact same way. -laugh- -sigh- -grin-

Yes, I have to say it has been very nice with Moose, though I wish  
MooseX::Declare and MooseX::Method::Signatures would move out of alpha  
(probably will happen around the first stable release of perl6).

>> ground-up rewrites of large projects almost never work.
>
> Ya, I wouldn't recommend a big bang approach. (Until BioPerl6?) The  
> whole idea is to turn the whole thing into lots of little bangs.  :)

I think bioperl6 will follow suit with a smaller bioperl-specific core  
(probably simple metaclass, exceptions, etc) and separate smaller  
focused distributions.  Bio::Moose similarly.

> Jason's list of targets is exciting! (Where's the Bio::Graphics SVN  
> repo?)

Rob's answered that one: GMOD.

> Anyhoo, I'll stop preaching to the choir now.
>
> Jay Hannah
> http://bioperl.org/wiki/User:Jhannah

chris