Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Friday March 03, 2006
02:52 AM

Some thoughts after an informal Module::Build brainstorming

[ #28855 ]

Ken Williams came chasing after me to get more information about a Module::Build/YAML bug I reported that was creating problem getting Bundle::CPAN compatible with Vanilla Perl (but more on Vanilla Perl in a week or so)

It turned into a sort of 3 way brainstorming between Ken, Matt Trout and myself on how Module::Build worked now, and might be improved.

So at least now I finally got the chance to bitch about Module::Build in person to Ken rather than just lobbing grenades at evangelists in mailing lists. :)

And as seems to be the case for most situations like this, a conversation with the main author of a system was far more productive than talking to users of the system that evangelise it.

It helped to confirm for me that my main technical issue with Module::Build is valid, in that Module::Build does not provide a clean install/upgrade mechanism for end users.

In talking Ken seems quite keen to deal with this, and we talked about how it might be fixed. But for the sake for having a link to refer others to later I thought I should journal what I'd call the three main Installer Patterns.

Anyone planning on implementing a from-source installation system of any type is going to have to implement one of the following.

Installer Pattern 1 - Frozen Installer

This is generally the weakest of the three.

It involves writing an installation system, and never changing the API (even to add features).

This is kind of the current situation with ExtUtils::MakeMaker. It pretty much never changes in any significant way, and so any ExtUtils::MakeMaker Makefile.PL should work with a hell of a lot of old versions.

But this has a ton of problems. Introducing features causes damage (because the installer itself might require a newer installer-support library to be written) and so once locked in there's no room for improvement.

Which pretty much describes ExtUtils::MakeMaker.

Installer Pattern 2 - Bundled Installer

This is the approach taken by the Windows .exe installers, and to a lesser extent Module::Install (which is a hybrid Bundled/Frozen Installer, wrapping bundled code around ExtUtils::MakeMaker)

It works best when you don't really trust the target environment to be consistent. Hence the popularity on Windows and in Perl :)

It also makes it very easy to add new extensions, as the extra code only needs to be added by the author, and nothing is needed on the user's side. And as long as the code works everywhere, everything is great.

On the downside, it can bloat out your package (in the case of M:I the extra 20K is really negligable though). But more importantly, if there is a major bug in your installer you need to do an incremental release of every package created. And so you need to be relatively careful that the features available work reliably for all end-users.

But because the installer makes almost no demands on the user's intelligence (remember, popular on Windows), it works in the most environments for the most users. And if you measure the success of an installer by, well, how many places it installs, then you can see how attractive this pattern is.

The other big downside to the Bundled Installer is that you need strong control over the authors. For CPAN we actually do, there are only around 3500 of them, and we control the upload point PAUSE.

Installer Pattern 3 - Upgrading Installer

When you don't control the authors as much, and don't want to bundle, how do you have a standard installer.

The dominant way for handling this situation is to allow the installer to auto-upgrade. Indeed, to maintain your sanity and not cause maintenance prolems you have to FORCE the installer to upgrade.

So if you use Windows Update, or Redhat Network, or the Steam Installer, every now and then when it starts up it will do the "Please wait while Installer 2.0 installs Installer 2.1..."

So where to with Module::Build

Until Module::Build implements one or both of these patterns, it is going to continue to suffer. And until it implements one or more of these patterns I certainly think it doesn't belong in the core. It won't have the unique stability and adaptability requirements required from an installer.

Of course, the third option would be the best, but is also going to require the co-operation of both CPAN.pm and CPANPLUS to somehow support version checking and auto-upgrading of the core installer components.

And Ken also wants elements of bundling involved, for some of the same reasons we use them in Module::Install, to do things like bundle small testing modules and reduce the number of dependency installer iterations.

Now, I doubt any of this will be available in 0.28, but my hope is that some time after 0.28, we see some capability for bundling, following by some level of integration with CPAN.pm and CPANPLUS to allow auto-upgrading of the core components.

Now flame away :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Looking at the MOTIVATION section of
    Module::Build's man page, I don't think you see
    any of the concerns of the problem of
    installation as outlined here. It was a more
    limited fixing of the problem of make and EU::MM.

    When did the issue of the problems of software
    users as distinct from software developers start
    to arise? After the availability of CPAN.pm and
    so on made it even easier than it had been to
    install modules?
  • Well, the problems have been there the whole time.

    The reason it hasn't come up sooner is that installer deficiencies of this nature are creeping problems.

    They build up gradually, and only start to impact strongly as the number of MB packages increases, and as the number of production versions of MB increases.

    As long as few people are using it, and it isn't changing quickly, you have a Pattern 1 situation. The installers don't break if the installer infrastructure is static.

    Add to that that most 9 out of 10,
  • I think this taxonomy is lacking because it confuses several different tasks:

    • Package management -- managing available/installed software and retrieving software to be installed from a repository
    • Installation -- putting pieces of code/library into OS/user-specific locations for later use
    • Configuration management -- telling installers how to do their jobs
    • Distribution creation -- creating bundles of code, configuration, and -- in some cases -- an installer
    • Authoring tools -- helping authors with non-distri