in reply to Re^4: Why Module::Build?
in thread Why Module::Build?

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.

Replies are listed 'Best First'.
Re^6: Why Module::Build?
by adrianh (Chancellor) on May 20, 2005 at 17:32 UTC
    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.

      For me there is a very big difference between "I prefer"/"I believe" and "The preferred method is"/"you should"...

      Take a look at what I said: ...read what his preferred Scenario was... I don't see how the distinction that you're drawing differentiates between what I said, and what he did.

      I suspect that you think I thought he did something different than he did. Allow me to clarify. I think that he encouraged people to do something really stupid. I think that this is a bad thing to do. I'm surprised that he didn't have the sense to realize that it was abysmally stupid, and I'm surprised that when it was pointed out to him, he didn't see that there was an issue.

      It seems that you don't think that this was a bad thing to do. Perhaps you've spent less time doing installations that install tons of things from CPAN. That process is already painful enough, anything that causes the installation to break half-way through isn't OK by me. I am less OK with it if you're causing trouble for people because you want to get into their faces and say, Look at me! I'm cool!

      Whether or not he followed his own advice, others did. With predictably bad results. If he hasn't released a CPAN module with that setting, then I consider that hypocritical. He encouraged others to do something that was guaranteed to cause complaint, and never chose to experience the complaints himself? Even though he claims that it was the method that he preferred??

      I'm glad that you found a way of expressing yourself that convinced him to change that wording. I'm glad that he added the traditional method to Module::Build::Compat. I don't think that it should have taken as long as it did.

      As for how long it was there, I assume that the language was there in the original Module::Build::Compat, which was written Apr 2 2002. It was removed on Oct 9, 2004. That's over 2 years. I doubt that I really was the first to point out that it wasn't a good suggestion. Which indicates that the official documentation said that for years.

        I assume that the language was there in the original Module::Build::Compat
        Yes, it was.
Re^6: Why Module::Build?
by demerphq (Chancellor) on May 23, 2005 at 12:14 UTC

    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