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

Chris Fields cjfields at illinois.edu
Wed Jul 22 23:30:11 UTC 2009


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.

> Perl programmers need to know how to install dependencies using some
> toolset (cpan, ports, packages, apt-get, etc...) and understand how
> the pieces fit together.  I'd *much* rather see us do the standard
> CPAN best practice dependency thing and then spend our time/effort
> building better tools and/or doing better science.

I agree.

> Even if we do Magic for them to make BioPerl appear to work they're
> going to be stuck as soon as they try to use any other CPAN module
> (and they *SHOULD* be using CPAN modules, but that's a different high
> horse altogether...) and we've just ended up creating fragile code
> that someone needs to support.

Exactly.  As I mentioned before, I would rather any bugs be CPAN or  
Module::Build problems, not BioPerl bugs.

> I'm working on moving my current project to use local::lib so that I
> depend on a well defined set of installed stuff and while I think
> local::lib sets up enough of an environment so that any automated cpan
> installs would do the right thing I'd rather not have to trust it.
>
> g.

I have thought about doing something along those lines for testing  
purposes, just haven't had time yet to set it up.

chris





More information about the Bioperl-l mailing list