See also: RequiredEnvironmentForTWiki
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
"Is it valid to create a TWiki dependency on certain Perl CPAN modules?"
- Whatever the conclusion, TWiki deployment should be as easy and painless as possible
- Use CPAN modules in the core where appropiate (we trust the Core Developers to do the right thing), as long as they:
- Are relatively bug free.
- Neither the module nor its dependencies requires a compile (ie, they are pure perl modules)
- 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.
- 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)
(feel free to add some)
Some useful links to the
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):
I'll propose to add this to the agenda in the next EdinburgRelease
- 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
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
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
). Instead, you can just do the following, which is equivalent to
, right where you need that module, subject to some tinkering for modules like Socket that create subroutines intended for use as C-style constants:
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
even if they don't import any symbols, so their
routine is called.
(Derived from ProperIncludeUrls
- 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
- 17 May 2003
The point of not doing
is to simplify TWiki installation, since this happens at compile time whereas
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.
- 17 May 2003