[Bioperl-l] bioperl reorganization

[Sendu Bala]

Chris Fields wrote:
> On Jul 16, 2009, at 2:22 AM, Robert Buels wrote:
>>> And finally, and I am saying this with the utmost respect and 
>>> sincerest thanks for everything Sendu is doing and has done for 
>>> BioPerl, but I'm not convinced we should keep using Bio::Root::Build. 
>>> It does make some things convenient, but at the cost of additional 
>>> bugs (2-3 at last count), some API breakage (some methods conflict 
>>> with Module::Build), and a bit of a chicken-and-egg dilemma that 
>>> particularly impacts subdistributions (attempting to fall back to 
>>> Module::Build doesn't work due to API issues).
[snip]
> http://bugzilla.open-bio.org/show_bug.cgi?id=2792
> http://bugzilla.open-bio.org/show_bug.cgi?id=2831
> http://bugzilla.open-bio.org/show_bug.cgi?id=2859
> http://bugzilla.open-bio.org/show_bug.cgi?id=2832 (this one is more a TODO)
> 
> Note that the author of Bio::Root::Build hasn't touched these, so my 
> inclination is to convert over to plain ol' Module::Build.

Well, it hardly had to be me that had to add CPANPLUS support. And 
they're all P2 normal and minor bugs. And you never (iirc) encouraged me 
to solve them to help out with your release. I did offer to help 
(generally), but you never took me up on that offer. But...


> On API and the 'chicken-or-egg' issue:
> 
> Several methods within Bio::Root::Build override Module::Build methods 
> but break API, in that they accept, generate, or process different 
> (sometimes bioperl-specific) data than what the same Module::Build 
> methods expect.  I think 'requires' and 'recommends' fall into this 
> cateory, as well as some meta data generation, such as META.yaml and 
> PPM.  Other bits are more akin to syntactic sugar (automated 
> installation via CPAN, network checking, etc).  This may cause bugs as 
> noted above, which goes to demonstrate that too much 'sugar' can send 
> you into a coma ;>

... You're right, it's a bit of a mess. For 1.5.2 I felt all the extra 
stuff that made it easier to install was absolutely required. And the 
ultimate purpose of Bio::Root::Build (as it's called now) was to make 
installation easier for everyone. If it makes it harder, and/or if the 
current maintainer thinks they can deal with any support requests that 
arise from just using Module::Build directly, then go ahead and do away 
with it.

But while BioPerl is still monolithic, how will people be able to choose 
which external dependencies they want to install? That's the question 
that must be resolved before getting rid of Bio::Root::Build. You'd also 
need to resolve the network tests issue. And, well, I guess all the 
other issues that Bio::Root:Build solves.


> It also causes a bit of a 'chicken-or-egg' issue with subdistributions 
> wanting to use Bio::Root::Build, in that one has to check for the 
> presence of Bio::Root::Build first and then completely bail if it isn't 
> present.  One can't fall back to Module::Build due to the API 
> difference.

For small sub-distributions that have no optional external dependencies 
(all of the BioPerl subdists?), they can be changed to just using pure 
Module::Build, while core retains Bio::Root::Build as long as core is 
monolithic.

(For 1.5.2, the subdists each came bundled with ModuleBuildBioPerl, so I 
didn't have this issue.)