[Bioperl-l] Regarding Bio::Root::Build, was Re: bioperl reorganization
hartzell at alerce.com
Thu Jul 23 02:03:09 UTC 2009
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
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
More information about the Bioperl-l