Tags:
cpan1Add my vote for this tag extract_stuff1Add my vote for this tag installation1Add my vote for this tag create new tag
, view all tags
See also: RequiredEnvironmentForTWiki, CpanContrib
Note: I severely refactored this topic. Twice.
  • The original text can be found on rev 1.53
  • The first refactored text with comments can be found at on rev 1.62


Main Question

"Is it valid to create a TWiki dependency on certain Perl CPAN modules?"

Guiding Principles

  • Whatever the conclusion, TWiki deployment should be as easy and painless as possible

Proposal

  • Use CPAN modules in the core where appropiate (we trust the Core Developers to do the right thing), as long as they:
    1. Are relatively bug free.
    2. Neither the module nor its dependencies requires a compile (ie, they are pure perl modules)
    3. Don't impact severely the performance.
  • Provide specific instructions on how to install the required CPAN modules.
    • Provide a script that downloads the required modules.
      • Plugins.BuildContrib can help here. It includes an installer script that downloads CPAN dependencies.
    • Keep Plugins.CPANContrib up-to-date with all the required CPAN modules, so it can be downloaded along the distribution in case of lack of access or experience to use CPAN.
      • CPANContrib must be an "unzip and done" package.
        • Why? I really, really don't want all the things it has in it.... (CC)
      • A way to keep Plugins.CPANContrib up-to-date with the latest version of the required modules must be investigated.
    • Publish Plugins.CPANContrib prominently in the download page as an alternative to install the required modules for TWiki.
  • Update the installation documents accordingly.

Advantages

  • Not relying on Unix binaries can make TWiki more portable.
  • Most people who can install TWiki, probably would have an easy job with CPAN modules.
  • If you can transport the TWiki.(zip|gz) to your server location, transporting other CPAN related files over the same mechanism should be possible. -- NicholasLee - 20 Jun 2001
  • Heavily used modules are very BUG FREE and are HIGH PERFORMANCE -- RaymondLutz - 07 Nov 2003
    • I wish that could be relied on, but recent experiences with CGI.pm suggest otherwise. It is critical that the mechanism is able to select specific versions of CPAN modules, and not rely on the "latest and greatest". (CC)

Disadvantages

(feel free to add some)

Useful links

Some useful links to the CPAN.pm docs:

A couple of useful docs about how to install Perl modules by hand under your home directory (i.e. when you don't have root access):

Comments

I'll propose to add this to the agenda in the next EdinburgRelease meeting

-- RafaelAlvarez - 13 May 2006

Stuff to be Refactored out

Additional ideas (to be factored out)

  • Make some modules loaded "on demand" using require instead of use -- RichardDonkin - 21 Aug 2002
  • Create a CPAN bundle for TWiki (http://www.cpan.org/misc/cpan-faq.html#How_install_Perl_modules)
  • Application (i.e. TWiki) code should not have any calls to any executables, they should be abstracted into a library. Examples of such libraries are the VCS::* modules that abstract the Rcs, CVS or SourceSafe use, and the CPAN module for Crypt, that can be used even if the program (crypt in this case) is not available in a given platform.
  • Get rid of setlib.cfg and LocalLib.cfg. TWiki should be useable by a simple -I lib on the perl command line; we should not depend on complex manipulations of @INC (a point observed by Alan Burlinson in his petulant anti-TWiki rant, which is nevertheless very valid)
  • Simplify all the scripts, and update the docs to ensure that users understand the need to set up PERL5LIB.

Guideline on importing CPAN modules

Generally, use Module should be avoided wherever possible in TWiki core code, as it incurs a module load overhead for just about every use of TWiki, and also creates a mandatory installation requirement (see CPAN and CpanPerlModulesRequirement). Instead, you can just do the following, which is equivalent to use MIME::Base64, right where you need that module, subject to some tinkering for modules like Socket that create subroutines intended for use as C-style constants:

require MIME::Base64;
import MIME::Base64 ();

Perl will take care of not re-importing a module if you go through the same code path twice. Some modules require you to do the import even if they don't import any symbols, so their import routine is called.

(Derived from ProperIncludeUrls)

-- RichardDonkin - 28 Jan 2003

Richard, regarding the advice above to "avoid doing a 'use Module'" - can you point me to the place in the Perl documentation that supports this? The closest I can find does not give this advice, it backs the use of autosplit as mentioned in ModuleLoadingPerformanceEnhancements. This http://www.perldoc.com/perl5.6/pod/perlmodlib.html#Modules--Creation%2c-Use%2c-and-Abuse

-- MartinCleaver - 17 May 2003

The point of not doing use Module is to simplify TWiki installation, since this happens at compile time whereas require Module is done at run time and can therefore be done conditionally. CPAN:MIME::Base64 was being loaded unconditionally in a TWiki module to handle a very specific case, for example. This is not a performance issue, since the same module load happens in both cases. Autosplit is a performance enhancement that enables only the actually used parts of modules to be loaded/compiled; however it would not change the installation requirement, I believe.

-- RichardDonkin - 17 May 2003


Contributors: NicholasLee, PeterThoeny, MartinCleaver, RichardDonkin, PeterMasiar, RobertBagwill, NicholasLee, JohnTalintyre, ThomasWeigert, ToddJonker, AndreaSterbini, CrawfordCurrie, RafaelAlvarez
Edit | Attach | Watch | Print version | History: r65 < r64 < r63 < r62 < r61 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r65 - 2006-05-13 - RafaelAlvarez
 
  • 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.