use Perl

• Not really talking about installers (Score:1)

  by dagolden (6584) on 2006.03.12 10:07 (#46571) Journal

  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-distribution related tasks, though ones which may be related to distribution (e.g. MANIFEST checks, test coverage checks, etc.)

  The problem is that there tends to be tight coupling between many of these, but we have decentralized and largely uncoordinated tools and different toolchain combinations are needed to handle these tasks. Roughly in order of number of components:

  1. CPAN, Module::Build (2)
  2. CPAN, ExtUtils::MakeMaker, make (3)
  3. CPAN, Module::Install, Module::Build (3)
  4. CPANPLUS, CPANPLUS::Dist::Build, Module::Build (3)
  5. CPAN, Module::Install, ExtUtils::MakeMaker, make (4)
  6. CPANPLUS, CPANPLUS::Dist::MM, ExtUtils::MakeMaker, make (4)
  7. CPANPLUS, CPANPLUS::Dist::Build, Module::Install, Module::Build (4)
  8. CPANPLUS, CPANPLUS::Dist::MM, Module::Install, ExtUtils::MakeMaker, make (5)

  Have I missed any? (I'm not even addressing Module::Build being used to generate a Makefile.PL, as that's Module::Build being used as an Authoring Tool to support #2 and #5 above. I'm also ignoring the complications that XS create.)

  I may also have missed some Module::Install variations, as I'm not entirely sure where it ends and the other components begin from a task perspective.

  I broke out the CPANPLUS::Dist::* ones separately, as *::Build is now a separate distribution -- in part to allow faster upgrades to the coupling between components.

  So there's anywhere from 2 to 5 different components, each of which are maintained separately and have separate release cycles. Is there any wonder this breaks?

  I like the Module::Install approach of bundling itself with the distribution because it helps a distribution to try to be good to users who have old versions of the other components. But it still sits on top of the rest of a cruddy toolchain, so it doesn't really address the core problem.

  Things I think might help the situation:

  1. I think refactoring the whole process around the individual tasks would help. I think CPANPLUS had the good idea of breaking up front-end administration from back-end distribution-specific plugins. CPAN should do the same.

  2. CPAN and CPANPLUS should aggressively try to auto-upgrade themselves if they can, and they need to be seamless doing so (no lengthy configuration steps).

  3. I'd like to see a CPAN.PL file that tells CPAN what installation plug-in to use. CPAN should then aggressively try to upgrade that plug-in or use one bundled with the distribution.

  4. Potentially, distributions would use the Module::Install technique to bundle CPAN and appropriate plugins to upgrade CPAN if that was out of date. Yes that's even more bloat, but space is cheap these days and CPAN 1.87 is only 242K. I'd rather see bigger but more robust distributions over smaller ones that break under older versions of the toolchain.

  That's my ramble for a Sunday morning. I think there's a lot more thinking that could be done about refactoring the whole process, but the big challenge will be getting the entire toolchain upgraded across current/legacy Perl's with and without network access. There, the Module::Install approach of bundling seems to have some interesting potential -- if anything, perhaps it doesn't go far enough!

  Reply to This