[Bioperl-l] bioperl reorganization
jay at jays.net
Fri Jul 17 18:49:28 EDT 2009
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
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
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:
> 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.
More information about the Bioperl-l