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

[Chris Fields]

Unless I'm misreading you I think that's how we're currently running  
things,  for instance in Annotation.t:

BEGIN {
use lib '.';
use Bio::Root::Test;

test_begin(-tests => 158);
	
use_ok('Bio::Annotation::Collection');
use_ok('Bio::Annotation::DBLink');
use_ok('Bio::Annotation::Comment');
use_ok('Bio::Annotation::Reference');
use_ok('Bio::Annotation::SimpleValue');
use_ok('Bio::Annotation::Target');
use_ok('Bio::Annotation::AnnotationFactory');
use_ok('Bio::Annotation::StructuredValue');
use_ok('Bio::Annotation::TagTree');
use_ok('Bio::Annotation::Tree');
use_ok('Bio::Seq');
use_ok('Bio::SimpleAlign');
use_ok('Bio::Cluster::UniGene');
}

The critical difference is we check (and skip tests for) bioperl  
modules which have a 'recommends' module dependency based on Build.PL,  
with requisite messages.  Bio::Root::Test has methods built in that  
check for modules required for a specific set of tests.  We're going  
by the Module::Build definition of 'requires'/'recommends':

1) requires - Items that are necessary for basic functioning.
2) recommends - Items that are recommended for enhanced functionality,  
but there are ways to use this distribution without having them  
installed. You might also think of this as "can use" or "is aware of"  
or "changes behavior in the presence of".

The distribution is so large it's hard to require the user to install  
all modules, particularly those used by one or two 'non-essential'  
modules, so we deem those as 'recommends'.  By non-essential, we mean  
they don't crash anything beyond their own tests (another reason I  
pushed for, and we eventually decided to, split up tests prior to the  
initial 1.6 release).  This is also one key reason to split bioperl  
into more manageable bits; splitting up tests also makes that easier  
(speaking of, my example above, Annotation.t needs to be split up  
based on each Annotation type).

If anything, our 'required' modules should be a good starting point  
for what we consider 'core', with everything else requiring additional  
'recommended' dependencies split off.

chris

On Jul 22, 2009, at 9:11 PM, Mark A. Jensen wrote:

> chiming in to +1 on this; seems very 'natural' (i.e. plugs into to  
> the Perl Common Sense, approximated by perl core modules + CPAN)
> ----- Original Message ----- From: "George Hartzell" <hartzell at alerce.com 
> >
> To: "Chris Fields" <cjfields at illinois.edu>
> Cc: "Robert Buels" <rmb32 at cornell.edu>; "BioPerl List" <bioperl-l at lists.open-bio.org 
> >; "George Hartzell" <hartzell at alerce.com>; "Mark Jensen" <maj.fortinbras at gmail.com 
> >
> Sent: Wednesday, July 22, 2009 10:03 PM
> Subject: Re: [Bioperl-l] Regarding Bio::Root::Build,was Re: bioperl  
> reorganization
>
>
>> Chris Fields writes:
>> > On Jul 22, 2009, at 3:14 PM, George Hartzell wrote:
>> >
>> > > Chris Fields writes:
>> > >> On Jul 19, 2009, at 11:15 PM, George Hartzell wrote:
>> > >>
>> > >>> Chris Fields writes:
>> > >>>> [...]
>> > >>>> Prior to Module::Build the Makefile.PL we just looked for the
>> > >>>> dependencies and reported back if they were missing;  
>> installation
>> > >>>> of
>> > >>>> those modules was left up to the user. [...]
>> > >>>
>> > >>> Chiming here a bit late to say that I really *like* it when  
>> we leave
>> > >>> installing the modules to the user.  I'd often rather install  
>> them
>> > >>> via
>> > >>> e.g. the FreeBSD ports system instead of system, but how/why  
>> would
>> > >>> BioPerl ever know that?
>> > >>>
>> > >>> g.
>> > >>
>> > >> That's a good point.  Leaving it up to the user does make  
>> things a
>> > >> lot
>> > >> simpler.
>> > >>
>> > >> The only downside is the onslaught of users who don't know why a
>> > >> specific module doesn't work.  May be the reason this was  
>> added in?
>> > >>
>> > >
>> > > If we keep our dependencies current and write use_ok() style  
>> tests for
>> > > our modules so that
>> > >
>> > >   ./Build test
>> > >
>> > > fails when a dependency is missing I think that we've done our  
>> part of
>> > > the job.  We might be able to pick up some automated way to check
>> > > dependencies (stolen from the autodepend Dist::Zilla plugin or
>> > > something) and increase our odds of staying on top of it.
>> >
>> > We have added some bits to the test suite (largely thanks to Sendu)
>> > for checking these things for us, so tests requiring a specific  
>> module
>> > are not run and a warning is issued.
>> > [...]
>>
>> What I was describing is a layer simpler than what Sendu et al. have
>> done.  In a module testing Foo, Bar::Bah, instead of
>>
>> use Foo;
>> use Bar::Bah;
>>
>> use
>>
>> BEGIN {
>> use_ok('Foo');
>> use_ok('Bar::Bah');
>> }
>>
>> and that way if there's some missing dependency that wasn't properly
>> specified/dealt with then it's handled as part of the framework,
>> "rather than just vomiting if its load fails" (in the words of the
>> Test::More author).
>>
>> g.
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l