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:

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

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):

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.

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.

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.

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.

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.

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.

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.

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!

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:

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