Then you're not looking hard enough :) From the beginning of Module::Build that has been its mission. Not when it's shiny, users will flock, but cram it down their throats, then get them to do it to others

I've looked pretty hard because people keep saying this - but I've yet to see any evidence. Hell Ken's said that EU::MM isn't going away. Hardly a sign of somebody trying to force everybody to use M::B :-)

What I do see is lots of people shouting past each other for no good reason. A little bit of the Charity Principle is needed.

See the old Module::Build::Compat. Scan for Scenarios, and read what his preferred Scenario was. (Do not use Module::Build::Compat. Include instructions in the README telling people to download and install Module::Build by hand.)

That was the official last word for years. And remained that way through many rounds of complaints. I'm not sure what changed his mind in the end, but I doubt that it was me. And until I see something to convince me that he really has changed, my impression of Ken will remain strongly flavoured by this episode.

See the old Module::Build::Compat. Scan for Scenarios, and read what his preferred Scenario was. (Do not use Module::Build::Compat. Include instructions in the README telling people to download and install Module::Build by hand.)

The text said:

Just include a Build.PL script (without a Makefile.PL script), and give installation directions in a README or INSTALL document explaining how to install the module. In particular, explain that the user must install Module::Build before installing your module. I prefer this method, mainly because I believe that the woes and hardships of doing this are far less significant than most people would have you believe. It's also the simplest method, which is nice. But anyone with an older version of CPAN or CPANPLUS on their system will probably have problems installing your module with it.

For me there is a very big difference between "I prefer"/"I believe" and "The preferred method is"/"you should", and he also mentions the major downside. I don't see the problem with somebody expressing a preference. I don't agree with it either - but I didn't see it as a diktat.

To the best of my knowledge, Ken has never released a CPAN module with this setting.

That was the official last word for years. And remained that way through many rounds of complaints.

The first report I'm aware of was 19 Sep 2003. Ken agreed to tweak the text on 20 May 2004. Eight months isn't "years".

I'm not sure what changed his mind in the end, but I doubt that it was me.

I think it might have been me :-)

And until I see something to convince me that he really has changed, my impression of Ken will remain strongly flavoured by this episode.

Fair enough. I'll just raise a hand and say that my experiences have been very different, and I'll still go along with the opinions of the M::B developers I expressed last year.

I wanted to say thank you. I think your comment in this thread and in your reply here cover my feelings about M::B very well, and also offer a good explanation of the mismatch between the views of Schwern and the M::B crew and the view that all to regularly is expressed here about M::B.

Most perlmonks first signifigant encounter with M::B will be when it breaks CPAN during a bulk install. There will be two reasons for this: first they don't have M::B installed anyway, second that they have M::B installed but somebody using it listened to the ridiculous advice about not providing a Makefile.PL.

The first is fixable more or less. I have to admit that I personally found this scenario particularly annoying for quite some as every time I tried to install M::B it died due to some silly non-portable oversight, or some other related forgetfulness related to deploying in a Win32 enviornment. Recent installs of M::B havent had this problem so presumably they have learned not to realease without doing proper Win32 testing first.

The problem of the second scenario is much more annoying, as I am one of those who for various reasons often has to use an old CPAN. In this scenario there is nothing I can do to prevent modules using M::B from breaking my module builds and generally adding stress and hassle to my day. Starting a bulk CPAN install which results in multiple failures because M::B using modules haven't provided a Makefile.PL is a real pain, especially when the M::B modules are prereq's that I didnt directly ask for and that were NOT using M::B the last time they were built. What this does is make me deeply deeply hate M::B.

The other side of this coin is what the M::B folks and module producers and people like Schwern see. They see M::B as a solution to a whole host of their personal project problems. Nightmare issues maintaining EU::MM (ive had patches applied to it, I know how twisty and horrible it is), handling nonstandard dependency requirements and the like are all easier in M::B than in EU::MM. Since these people presumably are more concerned with dealing with their direct packaging and installation problems than the spurious install issue related to old software it makes sense that they dont see any problem with M::B.

The problem with all of this is I dont see how the situation can be resolved happily except maybe M::B publically deprecating the use of Build.PL scripts and switching over to using Makefile.PL's always. Even then there is still going to be a lot modules set up with the old code which makes such a switchover less attractive than we might wish. Until there arent any modules out there that gratuitiously break CPAN its going to be hard for Ken and the M::B crowd to convince a lot of people that using M::B is a good idea. I think history has proved this, and that had Ken not taken this path he would have found himself with considerably more community support for M::B, both in switching over to it and to developing it as a project.

Oh and for the record I know that some people were saying this from the very beginning. Im sure I did when i attended Kens lecture at YAPC::EU::Munich.

---
$world=~s/war/peace/g