[Bioperl-l] "progress": useful changes vs. "shiny new thingie"
bosborne11 at verizon.net
Wed Nov 15 15:54:27 EST 2006
One problem here, as I see it, is the fact that this change has been
introduced just days before the intended release. Take a look at the page
that's supposed to describe 1.5.2 and associated work:
You won't find any mention of changing the build there, nor of Build.pl, or
Module::Build. This page is a nice example of "best practice", where
everything about the release is lined up and laid out, and making a big
change at the last minute is not best practice. Now, has Bioperl always made
a big deal out of best practice? No, but that's what's been nice about this
particular release so far, an emphasis on doing things correctly. That, and
having enough people to do the work!
Also, I understand that you think that your approach is better but such a
central change can't be adopted without discussion and some semblance of
consensus. So far I'm not getting any sense that anyone is agreeing with the
change but I am sensing discomfort with the idea, or resignation.
I have no strong opinion one way or another, Makefile or Build, but I do not
want to see significant changes at the last minute and I do not want
significant changes coming unilaterally.
On 11/15/06 2:33 PM, "Sendu Bala" <bix at sendu.me.uk> wrote:
> Aaron J Mackey/PharmRD/GSK wrote on 11/15/2006 01:29:30 PM:
>> What actual needs prompted the change from ExtUtils::MakeMaker to
> For the old Makefile.PL:
> At the time I started, script installation was broken. Documentation
> installation hasn't worked in a very long time. Handling of true
> requirements and optional pre-requisites is completely inadequate. It
> can't generate a suitable META.yml, and leaves the package non-ideal for
> distribution on CPAN.
> It was also a nightmare keeping the Makefile.PL scripts in each cvs
> module (live, run, db, network) in sync with each other. Now they can
> have simple module-specific Build.PL scripts, with all the advanced
> functionality in a rarely-updated and unchanged-between-modules
>> It seems that the switch was made without a complete understanding of
>> all the bits and bobs in the existing Makefile.PL
> I hope that's not the case; I tried to understand everything. Please let
> me know if I've missed something. (To tidy up a question I asked about
> the symlink script, I've resolved that and the symlink should also work
> given the proviso outlined in the POD for maintenance/symlink_script.pl)
>> For one, the Bio::DB::GFF Makefile.PL is independent (yet triggered
>> by the main Makefile.PL) such that users can choose whether to test
>> the install vs. a live database or not.
> The Makefile.PL in Bio/DB? As far as I can tell, it achieves no such
> functionality. Letting the user choose to do live database tests was a
> function of the main Makefile.PL, which I have carried over to the new
> Build.PL. (And made it better in the process.)
>> This is an example of encapsulation: the specializied testing/install
>> process for a module is kept with the module, and not in the
>> monolithic main script.
> From a maintenance point of view, it seems to me to be much easier if
> all install-related things are in one place rather than scattered where
> you might miss things.
>> For two, it seems that the ability to install bp_*.pl scripts was
>> "lost" in the transition.
> What makes you say that? It certainly shouldn't be. What should happen
> is you get asked what scripts you'd like to install (the same question
> as before), but again its done in a much nicer way.
> (The major difference, I suppose, is that scripts_temp is no longer
> generated; prior to "./Build install" you'll find the scripts in
>> For three, there's certainly a lot more that I can't remember right
> Please try and remember. I spent a lot of time trying to make sure that
> Build.PL does everything Makefile.PL did, but much much better.
> Thank you,
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
More information about the Bioperl-l