[Bioperl-l] Regarding Bio::Root::Build, was Re: bioperl reorganization

[Chris Fields]

I don't want to distract away from the reorganization discussion, and  
email lends itself only so much to the discussion (interspering  
comments doesn't lend itself to easy reading), so I've posted my  
response to my blog:

http://cjfields.wordpress.com/

I'm hoping that answers most of your questions and clarifies matters.

chris

PS : I don't think we're really that far apart on our thinking here,  
both on Module::Build/Bio::Root::Build and on restructuring.  We just  
need to actually get the work done and stop writing about it ;>

On Jul 19, 2009, at 10:28 AM, bix at sendu.me.uk wrote:

>> On Jul 17, 2009, at 11:54 AM, Sendu Bala wrote:
>>> Chris Fields wrote:
>>> 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.
>>
>> I mentioned two options.  The first was to revert back to
>> Module::Build. The second was to have Bio::Root::Build methods comply
>> with the Module::Build API.
>
> I'm not sure I follow. How does reverting back to Module::Build help  
> core
> installers choose what they want to install?
>
>
>> As for the external dependencies, we're falling into the trap of
>> thinking general users need to install bioperl-live (and thus are
>> using a tarball and 'perl Build.PL').  Everyday users should use CPAN
>> (or PPM when we have that running); devs and advanced users can use
>> bioperl-live.  A standard CPAN install should take care of most
>> required dependencies;
>
> No. B::R::Build's fancy stuff exists primarily for CPAN users. A  
> standard
> CPAN installation using standard Module::Build would force all users  
> to
> install all external dependencies for all BioPerl modules, even if  
> they
> only wanted to use 5 BioPerl modules that had no external deps of  
> their
> own. This is the main issue that is making it desirable for us to  
> break
> Core up into smaller parts.
>
>
>> we should be able to push additional
>> 'dependencies' onto the required queue if the user wants them.
>
> I'm aware of no such functionality outside of B::R::Build. Elaborate?
>
>
>>>> 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.
>>
>> The bugs mainly pertain to bp/M::DB API conflicts.  We could use
>> either/or if the API was the same, but it would be nice to have some
>> consistency and not have to choose between one or the other (or  
>> worse,
>> change from one to the other if a dependency is added).
>
> I Don't follow. A BioPerl subdist should never have optional external
> deps. The whole point of splitting Core into smaller bits is so that
> people can install only what they want. An optional dep means that  
> they're
> installing something they don't want along with something they do.
>
> Do you see a problem with my suggestion? I was actually thinking of  
> just
> going ahead and doing it: converting all the non-core dists to use  
> pure
> Module::Build. That will instantly solve all the problems except for
> people wanting to use CPANPLUS to install BioPerl core.
>
> And while that spoils the CPAN automated testing, we've never had a  
> single
> real user complain to us, have we?
>