[Bioperl-l] bioperl reorganization

[Jay Hannah]

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.


> 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/


> 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-


> 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.  :)

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

Anyhoo, I'll stop preaching to the choir now.

Jay Hannah
http://bioperl.org/wiki/User:Jhannah