[Bioperl-l] Regarding Bio::Root::Build, was Re: bioperl reorganization
Chris Fields
cjfields at illinois.edu
Mon Jul 20 03:43:20 UTC 2009
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
More information about the Bioperl-l
mailing list