[Bioperl-l] "progress": useful changes vs. "shiny new thingie"

[Nathan S. Haigh]

Hilmar Lapp wrote:
> On Nov 15, 2006, at 7:27 PM, Sendu Bala wrote:
>
>   
>> I would just want clarification that the consensus really is to stay
>> with Makefile.PL for 1.5.2. The primary argument seems to be to not  
>> have
>> anything too new and untested in the branch, but Makefile.PL itself  
>> has
>> lots of new additions. My Makefile.PL improvements and the change to
>> Build.PL have all been in the name of making 1.5.2 install well. The
>> move to Build.PL was just the most appropriate way to fix some bugs  
>> and
>> make needed changes.
>>     
>
> My take on this, aside from having said before that the move to  
> Module::Build is certainly a good one except with not-so-great  
> timing, is that the distribution if at all possible should have a  
> working Makefile.PL.
>   

I was in the process of writing a rather long e-mail to try to stem the
tide of Sendu-bashing :-P  But, this response serves as a better
platform for my comments.

I don't see the change to Build.PL as an issue - especially if we have
another RC. I think it would be worse to introduce Build.PL in the
"stable" 1.6 release than in the 1.5.x developer series.

I think one good reason for using Build.PL when Sendu brought the issue
up, is that it is more important as far as building a package for CPAN
rather than an end user - and since Sendu is the release pumpkin he is
the one with the strongest opinion for changing it now, rather than
later - it would make his job much easier!

I believe Sendu mentioned that a Makefile.PL would be included in the
CPAN package but is not in CVS as it would be generated from Build.PL
for backward compatibility - is that right Sendu? How does installing
via CPAN affect this? Does it give higher priority to Build.PL over
Makefile.PL and thus use Build.PL for the install?

> If Build.PL can coexist that'd be great. That would give you the  
> opportunity to have Makefile.PL print out a message right at the  
> beginning that if the installation process messes up one should try  
> Build.PL. This would spare you from fixing any problems in  
> Makefile.PL that are fixed in the Build.PL approach.
>   

Good idea, for anyone downloading the .tar.gz from CPAN if they issue
"perl Makefile.PL" without knowing Build.PL was there it should
hopefully work, but if not, issue a comment at the end  to say try "perl
Build.PL" if anything seemed to go wrong.

> As for CVS, I think Makefile.PL in CVS needs to be reduced to a stub  
> that just prints out a message telling you to use Build.PL and does  
> nothing else. If you check out bioperl-live from CVS you need to be  
> prepared to having checked out the live edge of the code. Edges can  
> be rough. The key thing is that the build process works.
>   

I was going to suggest something like this with regard to a Makefile.PL
in CVS. This would then be overwritten by the Makefile.PL produced from
Build.PL by the release pumpkin when making the CPAN package.

> Finally let's not forget that this is still a developer release. That  
> means that a) perfection isn't needed, rather shorter release cycles,  
> and b) development implies change. So the main reason why I find the  
> timing less than optimal is because it prolongs the time until the  
> next release.
>   

If we go for short release cycles, and regular bug fix release, we will
no longer have to say to users:
"This is a known bug/issue in release x.y.z, it has been fixed in CVS
HEAD so get it from there"
we can roll out fixes in regular releases. This way CVS is then used
solely by developers and those really wanting to live on the bleeding
edge code. Therefore, it is important to get Build.PL in place to let
the release cycle and CPAN packages built quickly, easily and without
hassle - which I believe is the problem with Makefile.PL as it currently is.

> Implementing changes like this do require a lot of energy. I very  
> much appreciate that Sendu invested the time and energy to make it  
> work, even though unfortunately at the last hour. Who knows who would  
> have had the energy after the release. If Sendu hadn't put in the  
> work now, the next release master may have been stuck with an even  
> messier Makefile.PL system. Instead of Monday morning quarterbacking  
> after no-one stopped him when he asked about it, we should all help  
> him make the release - and the build change - successful now that he  
> has done most if not all of the migration work already.
>
> 	-hilmar
>   

Here, here - well done Sendu on all your hard work!
Personally, I think the move to Build.PL is a good one - it may be a
little late in this particular release, but I think that the problem is
not that it is a late change, but that it wasn't picked up sooner. It
fits well with the goal of making releases and big fix releases more
regular, and if these are made available via CPAN, then the use of CVS
is for developers and those wanting to live on the edge. Build.PL helps
all this by making is easier and quicker to make CPAN packages. It also
means we have a while before the "stable" 1.6 release to ensure it is
working effectively - better than dropping it in on the 1.6 release
isn't it? I think it's work the delay and an extra RC!

Anyway, my 2 pence worth!
Nath

-- 
> A: Yes.
>> Q: Are you sure?
>>     
>>> A: Because it reverses the logical flow of conversation.
>>>       
>>>> Q: Why is top posting frowned upon?
>>>>         
Get Thunderbird <http://www.mozilla.org/products/thunderbird/>