module-build-general

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

[demerphq <dem...@gm...>]

On 2/16/06, Tels <nos...@bl...> wrote:
> Moin,
>
> the thread has grown a lot and spuried a lot of discussion, but I think
> there is still a lot of cross talk and people confusing things.
>
> Here is a quick summary - it hopefully clears the confusion[7] :-P
>
> 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]
>
> Pleasing U does, among other things, require to solve the chicken-egg
> problem.
>
> What Module::Build claims is that it pleases A and D. From that is infere=
d
> that U will also be automatically pleased. That assumption doesn't
> hold, tho.[2] Or it is claimed that U is also pleased.
>
> 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.
>
> * U is pleased:
>    "M::B based distros are easy for users to build & install." --
>     Randy W. Sims - http://tinyurl.com/9aob9
>   Bzzzt, wrong answer (or we wouldn't have the discussion!).
>
> * CYJU (CantYouJustUse)[3] CPAM.pm (or update whatever) - that just works
>   around the chicken-egg problem by saying "build a nest and the chicken
>   can lay the egg" - sorry :). It's nice when it works, but doesn't gain
>   anything when it doesn't[5] because it doesn't solve the underlying
>   problem.
>   See for instance: http://tinyurl.com/dltze
>
> So, Advice of the Day: don't mix the crowds and don't assume everyone is
> in the same crowd as you are. And don't sidestep questions, or deny that
> the problem exists. :)
>
> It is also worth noting that the U crowd is much bigger than A+D, which
> should be a sure sign that ignoring them spells doom in big red letters.
> [6] This doesn't mean you can ignore A and D's pleasing, tho.
>
> Best wishes,
>
> Tels
>
> 0: This includes the maintainer(s), because these are often the same, and
>    most, if not all problems apply to both of them.
> 1: This means that if A+D are pleased, but U not, we fail.
> 2: Sure, if A and/or D are so displaesed that they jump from a bridge, yo=
u
>    end up with a big mess and U cannot expect new features and/or delays.
>    However, if the current solution "works" for most in U, then replacing
>    it by a new solution doesn't "please" them - they are already happy. S=
o
>    if we displease U a bit to please the A+D crowd, we also fail.
> 3: I just love that. It's a red flag in German IT circles, too: "Einfach
>    mal nur" or "mal schnell eben", where "eben" =3D=3D "just" and "schnel=
l" =3D=3D
>    fast and "einfach" =3D=3D simple and "mal" means "this time" or "one
>    time" (see http://dict.leo.org/?search=3Dmal)
> 4: Note: When writing complicated Makefile.PLs - this does apply only to =
a
>    subset of D.
> 5: Maybe because you have one of the buggy CPAN installations, or are
>    not connected to the net, or can't run CPAN (like on VMS). Or, or, or.
> 6: Don't tell me you are not in the U crowd - in the near future you will
>    want to use your own code and it might just fail for you to install.
> 7: Yves also wrote the same, but in a more long message where it might be
>    missed: http://tinyurl.com/7o6dd
> 8: "please" means: "makes things better, or at least not (much) more wors=
e
>    for them.

Wow tels!

I tried to write a summary like this, but failed to come up with
something that abstracts out the issues as well.

Thank you very much.

PS: I cc'ed the MB and EUMM folks on this. No good summarizing if all
the relevent people arent going to see it, but maybe me sending it is
for the beter anyway, as im on the MB list so it wont go into
moderator purgatory when it comes from me.


yves
--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

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

[Yitzchak Scott-T. <sth...@ef...>]

On Thu, Feb 16, 2006 at 06:42:27PM +0100, demerphq wrote:
> PS: I cc'ed the MB and EUMM folks on this. No good summarizing if all
> the relevent people arent going to see it, but maybe me sending it is
> for the beter anyway, as im on the MB list so it wont go into
> moderator purgatory when it comes from me.

Just a reminder to anyone interested in posting to
mod...@li... but not actually wanting to
receive all the messages that you can "whitelist" yourself by
subscribing and then setting the nomail option.

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

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

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.


>>
>> 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.

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.


>> 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 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.

Who is making such an inference, anyway?


>> 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.

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.

  -Ken