[Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMakerin5.8.8 for UINST=1

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

On 2/16/06, Adam Kennedy <cp...@al...> wrote:
> demerphq wrote:
> > On 2/15/06, John Peacock <jpe...@ro...> wrote:
> >> Adam Kennedy wrote:
> >>>> to be even easier.  But "perl Build.PL; ./Build test; sudo ./Build
> >>>> install" is a close second.
> >>> That doesn't work for me, 50% of my machines require an alternative
> >>> syntax of
> >>>
> >>> C:\Program Files... etc etc
> >> Directories with spaces are evil (but I'm sure you know that already).
> >> Build.cmd (or Build.bat) support may or may not make it into M::B 0.28=
,
> >> depending on how motivated people are, since Ken/Randy are trying to g=
et 0.28
> >> out the door RSN.
> >>
> >
> > Actually i think that this is not that well known advice and it should
> > probably be added to the perl docs.
> >
> > Perl and everything that Perl uses for installation via CPAN should be
> > installed ONLY into spaceless paths (in you want a low pain life that
> > is). The easiest way to make your CPAN life hell is to put your
> > compiler (im my case VC7) in a path with spaces in it.
> >
> > IIRC the AS installer defaults to a non space path. C:\Perl iirc (i
> > usually override this so i dont remember for sure).
> >
> > Although Adam, i think its fair to say that in your case you should jus=
t do
> >
> > set path=3D%path%;LOCATIONOFYOURPERL
> >
> > before you use MB.
>
> The problem is not me personally.
>
> Like pretty much every person on this list, I know enough to work around
> such problems when they come up.
>
> The problem is for people that aren't on this list. At Sydney.pm last
> night I met one of the maintainers of TWiki. It was enlightenment.

Ok. Im sorry, i had the impression you were mostly dealing on a work
context where many machines are present. Of course these things are
trial and error for a newbie. And also the docs could be more helpful
in this area.

> For his userbase, the "things we don't tell you about using
> Module::Build" would look like.
>
> - The zip file won't work on its own, you need to install this thing
> called Perl first.
> - You can't click anything, you have to go to start -> run and type in
> arcane commands.
> - You can't install Perl in the normal Program Files location, you have
> to install it in c:\perl like an old DOS program.
> - You have to answer a whole bunch of technical jargon-loaded questions
> in the CPAN(PLUS) first-time process.

To be fair to the Module::Build crew I think its worth pointing out
that the above applies to any install that happens via CPAN, and at
least one of those points applies even to ppm.

> - You can't install modules with Build.PL using the CPAN installers that
> come with Perl, you have to upgrade them first.
> - You can't install modules with Build.PL through the CPAN installer,
> you have to manually install Module::Build directly first.

Ok, these are MB issues in my mind. And are consequences of what i
consider to be bad design decisions early in the process.

> This sort of situation is why we try to place a focus on making it
> easier for the users. What's the point of making things easier for
> authors if you end up serially annoying or altogether excluding 99% fo
> the potential userbase.

Yes i agree.  In my view this has been the main misunderstanding of
the MB project. The folks involved were very focued on author related
concerns to the detriment of user related concerns. And typically when
MB was criticised someone would come out of the woodwork and tell us
how happy we should be as MB was much easier to extend and that we
should just get used to MB because it was the future. (We even saw
something along those lines in this thread.)

The problem is they didnt seem to grok that very few of us cared if MB
was easier to extend or maintain than EUMM was.  All we wanted to do
was install some package on CPAN using the usual tools and were
prevented from doing so because MB was in the picture somewhere.

And in my mind, the author focus had some interesting consequences.
Users are generally not that clueful, and people trying to install a
module because it supposedly solves some problem that they need to
solve arent going to spend a lot of time debugging why the module
failed. What they would see is a failure and that module build was
involved and that any time they expended on figuring out why would be
wasted when they could just go and find a different module. So no bug
reports. (Or rather less bug reports than they probably needed). Not
only that but author level users are more likely to have taken time
and care in setting up their system, so the feedback there was
probably less typical than it would have been if every install failure
had been reported.

Expecting users trying to install module X to diagnose and the report
a failure in Y that is only in the picture because its the installer
is unrealistic. Only a module author level programmer has the skills
to even begin the process, and even there that assumes they have time
to do so. What i reckon is much more likely is that there are a lot of
MB related bugs filed against various module X's out there, and much
less reports directly to MB.

I mostly write this because I think that there are lessons to be
learned from this. MB is a good idea, everybody who has had to fight
with EUMM knows that. But the project made some signifigant mistakes
that should be noted and learned from.

Yves

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