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

[Rob K. <rob...@gm...>]

On 2/16/06, demerphq <dem...@gm...> wrote:
> 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.)

This points out a very big and well-known difference between the
author and user communities. More below.

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

I think the biggest lesson is that the toolset(s) used by the author
to build and package the distro shouldn't be the same toolset(s) used
by the user to install the distro. Oh, the author's Build.PL (or
whatever) should be available for those 1% of uesrs who are actually
interested in extending a distro. But, it shouldn't be what the user
HAS to use.

This has come up in several incarnations on the MB list in the few
months I've been lurking. Most recently, there was the discussion on
author tests vs. installation tests. This past week, I've been trying
to figure out if it's worth my time to create an Author.PL that I use
when building which creates and uses a subclass of MB and provide a
Build.PL that uses the "stock" MB. In discussions with other CPAN
authors, the sentiment has been near-complete agreement with the need
for such a distinction. And, I think this ties in with the move to
split out the functionality in EUMM into manageable pieces that can be
depended upon separately.

As for Win32 ... what's wrong with having something that creates a
.msi? There are free (as in beer) installer makers that will create a
full installer. Need some modules? Put them in there! Need Perl? Put
it in there! Let the installer figure out what's needed for
installation (and where to put it!) and what's not.

As for requiring "C:\perl", that's a whole lot of people not
understanding how to make Win32 work for them. I don't know what the
solution is as I'm not a Win32 expert, but I know it has to be there
because Win32 is that easy for the user to use and for the developer
to develop to. The plethora of shareware points to the fact that there
are tools we as a community are not using. And, we should be.
Supposedly, the Perl community is one of the premiere hacker
communities. We can't ALL be Win32-clueless.

In short, I think we need to do the following:
1) Create a harder separation between the installer functionality and
the builder functionality. I would LOVE to see a Module::Build::Author
and a separate Author.PL become a community standard.
2) The Win32-capable among us should be providing some direction as to
the tools we're not using. If you know a shareware author, find out
what they used to build and package their product for installation.
Italian teenagers are writing software that's easier to use than ours.
What are they doing that we're not?

Rob