[Bioperl-l] Regarding Bio::Root::Build

[Chris Fields]

On Jul 23, 2009, at 1:00 PM, bix at sendu.me.uk wrote:

>> On Jul 19, 2009, at 8:29 PM, bix at sendu.me.uk wrote:
>>> 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).
>
> OK, and given what the others have said, perhaps we shouldn't take  
> this on
> as our responsibility. So, just say that everything currently
> 'recommended' is 'required'? Is that what we really want to do?
>
> (The opposite, to say that nothing is required, would be really very
> broken behavior for CPAN and other packing systems)

Actually, the answer's both 'yes' and 'no'.  We should leave them as  
'recommends' until we split off packages that would end up requiring  
them (and it those packages, set them as 'requires').

>>> 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.
>
> IIRC what B:R:Build is supposed to do is exactly that: not spawn a new
> shell but simply to make CPAN think that the user's desired  
> recommended
> modules are actually required prerequisite modules. Then CPAN handles
> those in the normal way.
>
> If this isn't happening, then something is broken. CPAN should only be
> loaded when B:R:Build detects that CPAN isn't currently running.

If that is what is going on already then we're okay on that point.  
It'll become less and less necessary to worry about that as we break  
away modules with those prerequisites.

The method used to check for the shell process isn't fullproof and  
doesn't catch all cases (for instance, if you are running CPANPLUS  
shell instead).  What devs use now is look for env var CPAN_IS_RUNNING/ 
CPANPLUS_IS_RUNNING; if both are set, you are running CPAN, if only  
the latter, CPANPLUS.  I would just look for either/or and turn it off.

Also, we are attempting to load the proper version of Module::Build  
prior to actually running (in BEGIN block).  I think that's where we  
were running into the weird looping issue; if Module::Build doesn't  
install correctly for whatever reason, we don't have the correct  
version, so it tries over and over.  Should that just be a  
'build_requires'?

I'll see if I can come up with the conditions to replicate that.

>> 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.
>
> OK, I propose to look into these. Almost certainly I'll be doing  
> "convert
> run/db/network to Module::Build". I'll try to resolve the bugs you've
> mentioned.
>
> It might be a week or so before I get started since I'm currently on
> holiday away from a usable computer.

That works for me.  I can spend more time on getting on new point  
release ready, we can merge over changes when they are made.

chris