Fwd: [Module::Build] Re: Summary was: Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker

[Ken W. <ke...@ma...>]

[Forwarded from Tels]

Begin forwarded message:

> From: Tels <nos...@bl...>
> Date: February 18, 2006 5:40:12 AM CST
> To: Ken Williams <ke...@ma...>
> Subject: Re: [Module::Build] Re: Summary was: Re: something broken 
> between Module::Build, CPAN.pm, and ExtUtils::MakeMaker
>
> Moin Ken,
>
> (I am not subscribed, so this reply is personally. You can forward this
> email to what list you see fit :)
>
> On Saturday 18 February 2006 05:44, you wrote:
>> Hi,
>>
>> This summary, like any summary, is most appreciated.  It helps me to
>> clarify where I see things differently, though I agree with some of
>> what's being said here.
>>
>>> On 2/16/06, Tels <nos...@bl...> wrote:
>>>> For any module, especially the ones for installing other modules
>>>> (e.g. M::B, EUMM, M::I and CPAN) there are three (not nec.
>>>> distinctive) crowds:
>>>>
>>>>   * A - the original source code author and maintainer.[0]
>>>>   * D - developers, e.g. other people who want (or must, via
>>>> dependencies)
>>>>     use the module in their code. Often includes A, too.
>>>>   * U - mere users, who just want (or must, see above) to _use_ the
>>>>     module's functionality. Can also include A and D.
>>>>
>>>> Fact of the Day:
>>>>  Any module which wants to replace the current build system (EUMM)
>>>> must
>>>>  please[8] all three crowds or it will fail.[1]
>>
>> M::B is of course trying to please all three of A, D, and U.  I had
>> hoped that would be obvious, but in case it's not, I'm re-stating it.
>
> Thanx for that. :)
>
>>>> Pleasing U does, among other things, require to solve the
>>>> chicken-egg problem.
>>
>> Well, M::B is a chicken which knows how to lay itself as an egg.  And
>> CPAN and CPANPLUS or whatever tool know how to install M::B because it
>> ships with both a Build.PL and a Makefile.PL and has since nearly day
>> one.  So at the top of the dependency tree there's a terminus.
>
> I appreciate the work you are doing and I didn't want to imply that 
> M::B
> is "bad" in this regard. What I meant to say is that M::B has a certain
> disadvantage (namely being not core and not "here" on most machines" 
> and
> this it must overcome it. That disadvanatage is, of course, not M::B's
> fault. But it is still there and you can either work around it (make it
> "easier" to use M::B as you do) or remove it (by making M::B core and
> then wait some time until all Perls are replaced).
>
>> The issue is thus reduced to making sure other distributions can
>> declare their dependency on M::B in a way that the tools will
>> recognize.  M::B::Compat is our current solution for this.  It
>> generates three different kinds of Makefile.PLs for authors to include
>> with their distributions.  We've put a lot of work into them, which
>> should be Exhibit A for showing that we care about such users.  I'm
>> sure we can improve our tools, but I do want to make it clear that 
>> they
>> exist and have since April of 2002.
>
> I think the point you missed is that there is *still* a disadvantage to
> M::B unless it gets core. And that people wanting install Foo::Bar 
> might
> have to install M::B first or update whatever, and this is not their 
> main
> goal. (The "Cant you just" covers this very nicely.) People simply get
> anoyed when they have to do things that are not really related to what
> their goal is - even tho it might be for the betterment of their 
> systems,
> world peace ect :)
>
> I know, you make it as easy as it can be, and work hard that it is as
> painless as it is. A lot of confusion stems from that fact that 
> somebody
> claims "M::B makes things hard (I suddenly have to install it, update
> CPAN etc") and then people come out and say "M::B is easy". Yes, it is
> easy, but it is still a bit harder than the current way. And thus
> perceived as "unneccessarily hard".
>
> IMHO no matter how easy you make it to install/use Module::Build, it 
> will
> fail for someone, or someone thinks it is too complicated and thus
> complains.
>
> My summary was all about how these complaints are answered. Did this 
> make
> it more clear?
>
>>>> What Module::Build claims is that it pleases A and D. From that is
>>>> infered that U will also be automatically pleased.
>>
>> I have never ever made such an assertion.
>
> I did not speak about any one in particular, should have made this more
> clear.
>
>> I do understand that there
>> are issues U considers critical that A and D don't really care much
>> about (unless they're wearing their U hats).
>>
>> Also, we do indeed try to please U in M::B.  Witness for example the
>> 'diff' action, and the fact that a huge motivator for the entire
>> project for me is to be able to generate *good* rpms/debs/ppms/etc for
>> any M::B-using CPAN module.  There's an immense infrastructure
>> necessary to do that well, and probably A and D will never care about
>> it at all.
>
> As I said, the work is appreciated, but this must also be communicated 
> to
> the users.
>
>> Who is making such an inference, anyway?
>
> Thats the impression I always get when U complain and somebody steps 
> out
> and tells us that A+D are very happy. Some people even go as far as to
> say that their easy-of-packaging trumps the user's desire to use the
> software :)
>
>>>> So, we have critism from U about not being pleased (Adam writes
>>>> about this, for instance). To this there are responses along the
>>>> lines:
>>>>
>>>> * U might be displeased or not, but D is very pleased[4]:
>>>>   http://tinyurl.com/du7yc
>>>>   Bzzzt. Wrong answer.
>>
>> It's here that you lose me.  I don't know if "Bzzzt. Wrong answer" and
>> the advocacy in the rest of the message is really "summary" fodder.
>
> These were specific examples of the main point, namely that people get
> confused a bit who's wanting what. The advocating was intentional, tho 
> I
> did cut it down as much as I could without losing the message.
>
> Maybe I should have choosen a better subject or sep. the parts of the
> message.
>
>> Anyway, we've identified some things about the Makefile.PLs that can 
>> be
>> improved.  We'll do so.
>>
>> Specific issues we can fix, or at least identify, are great.  But I
>> resent some of the implications going around that our whole philosophy
>> of the project is wrong, or that somehow we're evil for wanting to
>> create and release a better build system.  These things are
>> complicated, and if some area is substandard that's because it needs
>> tuits, not because we don't care about our users.
>
> Agreed. I did _not_ want to convey the meaning that M::B is bad, or 
> wrong
> or whatever. But wether your efforts are appreciated by the very people
> who have to use them depends not only on the "work" but also on the
> "talk" :)
>
> Thanx for your response,
>
> Tels
>
> -- 
>  Signed on Sat Feb 18 12:15:40 2006 with key 0x93B84C15.
>  Visit my photo gallery at http://bloodgate.com/photos/
>  PGP key on http://bloodgate.com/tels.asc or per email.
>
>  This email violates U.S. patent #5,978,791 <http://tinyurl.com/5t6ft>
>