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

[Chris Fields]

On Jul 19, 2009, at 8:29 PM, bix at sendu.me.uk wrote:

>> 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.
>
> Unfortunately, it doesn't. You've only reiterated what you've said
> previously in this thread, but didn't yet address my questions.

Which ones? These?  I have answered them, either in the post or in

> I'm not sure I follow. How does reverting back to Module::Build help  
> core
> installers choose what they want to install?

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.  I don't necessarily think it's  
our *responsibility* to make the job easier for the user to choose and  
install modules other than BioPerl.  We just need to indicate what  
they may need to run certain modules (the warnings about missing  
recommended dependencies).

If we take on the additional responsibility to allow users to both  
choose the modules and call CPAN and have them installed during the  
Build.PL script, it has to work under conditions we may not be able to  
completely control.  The infinite loop bug, which I believe may be a  
combination of Gbrowse net install and a bad Module::Build, is an  
example of that.

I am merely suggesting we only allow the CPAN installation option  
under certain circumstances (i.e. only during 'perl Build.PL', not  
within the CPAN or CPANPLUS shell, or when recursing).

> I'm aware of no such functionality outside of B::R::Build.  
> Elaborate? (re: recommend/require queue)

Determining what is recommended/required (and checking for them) is  
handled within Bio::Root::Build, is that correct?  We could make those  
decisions prior to creating the instance, or take care of this  
internally (rearrange 'recommends'/'requires' based on what the user  
wants).  When in CPAN/CPANPLUS shell push the installation of those to  
allow the currently running shell to do the installation; don't spawn  
an additional shell. That's all.

This would allow CPAN/CPANPLUS (and possibly future implementations)  
to take care of installing the modules for us.

> And while that spoils the CPAN automated testing, we've never had a  
> single
> real user complain to us, have we?

I believe bug reports count as complaints.  Granted, a couple are from  
me (indicating problems I found during 1.6.0), but I assure you they  
are legitimate.  A third report from me was actually from a user on  
the list (links in the report), another is an independent report  
indicating CPANPLUS installation problems re: META.yml.

As CPANPLUS is being adopted by a lot of devs and it is used quite  
extensively in CPAN testers, I would really like to see it working; by  
far the largest proportion of UNKNOWN reports are due to CPANPLUS  
issues.

> In any case, you suggest a number of possible solutions, but which  
> one are
> we actually going to go for?

If it's easier to fix Bio::Root::Build in a way that addresses the  
bugs reported (the ones I indicate), then I'm okay with that. I trust  
whatever it is you want to do.

The three critical issues (as I've pointed out before) are:

1) Getting CPANPLUS installation working, which may be just META.yml,  
or it may be shell-related.  I would like it for CPAN Testers, if for  
nothing else.  That's at least 2 bug reports, maybe more.
2) Bio::Root::Build converted towards a Module::Build-compliant API,  
or we'll need to convert run/db/network to Module::Build.  1 bug report.
3) Avoid potential infinite looping. This may be Gbrowse-related via  
the net install script, but if Build.PL is being called in some way  
that potentially causes recursion we need to be aware of it. This one  
appears rarely, but I did manage to replicate it using an old  
Module::Build (I can't recall if I used the net install script or  
not). 1 bug report.

chris