[Bioperl-l] bioperl reorganization

[bix at sendu.me.uk]

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