Tags:
create new tag
, view all tags
To CPAN or not to CPAN ... that is the question. Whether 'tis nobler in the mind to suffer the slings and arrows of outraged newbies, or take arms against the CPAN modules, and by installing, help them.

The recently contributed extensions installer was severely and unpleasantly flamed, due to it's reliance on an unpublished CPAN dependency. While it's obviously wrong for software to fail in the face of missing modules - it needs to at least fail gracefully - there is a wider debate related to CPAN dependencies in general. This has probably been discussed in other topics before - if so, and you think they have something useful to add, please link them here.

There are two sides to this argument:

  1. Some people believe that CPAN is the single strongest reason (perhaps the only really good reason) for using perl. CPAN libraries offer a wealth of pre-coded and tested solutions which, while they are not always perfect, offer a tremendous advantage to any project that uses perl. A developer using CPAN modules is able to deliver reasonable quality solutions in a fraction of the time it would take to prototype the equivalent functionality in a less well-favoured language. Maintenance of CPAN modules is to all intents and purposes 'free'.
  2. Others take the standpoint that CPAN is evil. Many modules are poorly written, stodgy and inefficient. Some break when their authors generate maintenance releases, so not all versions are good. This creates potential for what Peter calls 'DLL hell'. CPAN assumes it will be installed by an admin, so it creates a real problem for newbies and the underprivileged installer. Dependencies that have to be resolved outside the released codebase can create problems for installers who have 1980's firewalls that block internet access for the CPAN installer.

I have to say at this point that I agree with all the points on both sides of the argument above. This topic is not about who is right and who is wrong. It is about how to solve the problems.

So, what solutions have been proposed? Starting from the oldest viewpoint first (with their main champions over time):

  1. Ship all required CPAN modules with TWiki (PeterThoeny)
    • Recode CPAN modules that require compiled code as pure perl.
    • Code lighter, TWiki-specific solutions for CPAN modules that carry a lot of baggage.
    • Don't require install tech more sophisticated than unzip.
  2. Create a methodology for the underprivileged to install CPAN modules (WillNorris)
  3. Script the entire install process, including Apache config (MichaelSparks)
  4. Create installer scripts that handle the dependencies for you (CrawfordCurrie)
  5. Bundle TWiki as a CPAN module (no champion)
    • This has the huge advantage of leveraging the CPAN installer to do all the installation work.
  6. Create installation bundles (APT, RPM, W32Installer etc) for major OS distributions that include the CPAN modules (SvenDowideit)
    • Has the added benefit that TWiki may get picked up and distributed by others, so potentially a strong marketing tool.
  7. VM bundles (SteffenPoulsen)
Examining these in turn:
  1. Ever since most of the original core team drifted off the project, TWiki has always been undermanned. The project does not have the development resources to enjoy the luxury of duplicating CPAN modules. If sufficient developer resources can be made available to the project, then it might fly.
    • It's hard to motivate anyone to duplicate CPAN work. However there is definite merit in some small, focused solutions to specific problems. TWiki::Time is a good example of a module that could be done using CPAN, but only by importing a mass of baggage.
    • Shipping local versions of modules is more credible, though it creates two problems: (1) installation bloat and (2) version hell, when an admin has to deal with multiple versions of the same module on their system.
    • Making this approach a requirement throttles the project, as developers can't add new features that leverage compiled CPAN modules.
  2. This was quite extensively explored by WillNorris. Unfortunately Will received little or no support or encouragement for this work, and has since abandoned it.
    • CPAN mini-mirrors, and installing CPAN to local dirs, are great ideas. Indeed, it's what I do on my local platforms to avoid polluting the global perl module namespace. But the scripts developed to date are pretty impenetrable, and it's questionable whether anyone would pick this work up from where Will left it.
  3. Again, Michael received little or no support for this work, and has since been kicked out of the TWiki community.
    • Maintaining a full front-to-back installer is undoubtedly the best solution for the admin. However it is a huge amount of development and maintenance work, and without a champion, is unlikely to go anywhere.
    • With a motivated champion, this could be great.
  4. This is a halfway solution in terms of effort, and quite a few people have contributed to BuildContrib to try and make it a reality. However much work remains.
    • There is no local CPAN install support, there are dependencies on CPAN modules in the installer itself that need to be coded around, and there needs to be extensive testing on a wide range of platforms.
    • BuildContrib already generates an installer script that potentially could be used to resolve CPAN dependencies for TWiki. Unfortunately the script is not able to target local CPAN installs, and relies on LWP for downloading.
  5. IMHO shipping TWiki as a CPAN module really just exports the install problem somewhere else.
    • TWiki is an application, not a reusable code library, so this may not be an appropriate approach.
    • With the right champion, it could probably be made to work. Without a champion it is a non-starter.
  6. Creating installation bundles is a lot of work, and while Sven is doing great work, this will only work as long as he remains committed.
  7. VM bundles are great for some people, but are not for everyone. Again, this is dependent on Steffen's continuing commitment.
My personal opinion is that the best/simplest/cheapest approach is to build a scripted solution to creating local CPAN install areas into BuildContrib, and use the installer script it generates to install TWiki. At the end of the day, the solution will be dictated by whoever is prepared to do the work, of course, so this is just opinion.

-- Contributors: CrawfordCurrie - 30 Nov 2006

Discussion

I agree with all you are saying - which is of no help altogether. I am afraid there is no one-size-fits-all.

From a customer's point of view, it depends on...

  • ...whether TWiki an established corporate tool, or just somebody's personal information manager. In the first case, a company will be more likely to invest in knowhow to install, and to maintain a TWiki installation. VM bundles or installation bundles can't be easily upgraded.
  • ...the quality of the CPAN module. Widely used modules often are of high quality, with less errors than TWiki releases ever had (or will have if we try to duplicate these modules). Many, but not all of those can be installed in arbitrary directories, by non-root users.

Probably "the solution will be dictated by whoever is prepared to do the work" isn't bad at all!

-- HaraldJoerg - 30 Nov 2006

For me CPAN is the incarnation of hell on earth: CPAN will never do twice the same thing on 2 different machines, it takes ages to run, its output is so verbose as to be incomprehensible... But I just realized that we do not have to use CPAN, as there is a much better alternative... debian packages !!!

Most CPAN modules are actually packaged as debian packages, which gives you fast, error-free, terse, consistent installs. I have even written a little script to automatically find the debian package installing a perl module:

#!/bin/bash
# cpan2deb modules...
# finds the debian package implementing a module
# e.g.: cpan2deb  CGI::Session  Locale::Maketext::Lexicon Time::Local
#
for m in "$@"; do
  echo "require $m;" | if ! perl 2>/dev/null; then 
    deb=`wget -q -O - 'http://packages.debian.org/search?searchon=contents&keywords='${m//:://}'.pm&mode=exactfilename&suite=stable&arch=any'|grep 'href="/etch/.*perl'|sed -e 's/.*">//' -e s'/<.*//'`
    if test -n "$deb"; then
      echo "# To install perl debian package $m do:"
      echo "    sudo aptitude install $deb"
    else
      echo "# *** Could not find debian package for $m"
      echo "# its name should be: `echo lib${m//::/-}-perl|tr '[A-Z]' '[a-z]'`"
    fi
  else
    echo "# $m already installed"
  fi
done

-- ColasNahaboo - 28 Jan 2008

(Clarification; Colas is referring to the perl module CPAN.pm, which installs other CPAN modules and is itself a CPAN module. He is not being negative about other modules on CPAN, just CPAN.pm)

I also find the CPAN.pm output pretty incomprehensible. it's also poorly documented. Despite that I use it because it works the same way (ish) on all my target platforms. Debian packages, unfortunately, only work on Debian (and some derivatives).

-- CrawfordCurrie - 28 Jan 2008

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2008-01-28 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.