comp.lang.perl.modules The Perl 5 Module List (Reusable Software)
Section 1 of 5 - Prev - Next All sections - 1 - 2 - 3 - 4 - 5
Archive-name: perl-faq/module-list
Revision: 2.49
Posting-Frequency: bi-weekly
URL: http://www.perl.com/CPAN/modules/00modlist.long.html
The Perl 5 Module List Revision: 2.49 $Date: 1998/08/15 08:53:26 $
======================
Maintained by Tim Bunce and Andreas König
Contents
Introduction
Where Are The Modules Kept?
Playing Your Part
How To Get a More Recent Copy of the List
Editorial Information and Copyright
Part 1 - Modules: Creation, Use and Abuse
1) Perl 5 Module Terminology
2) Guidelines for Module Creation
3) Guidelines for Converting Perl 4 Library Scripts into Modules
4) Guidelines for Reusing Application Code
Part 2 - The Perl 5 Module List
1) Module Listing Format
2) Perl Core Modules, Perl Language Extensions and Documentation Tools
3) Development Support
4) Operating System Interfaces, Hardware Drivers
5) Networking, Device Control (modems) and InterProcess Communication
6) Data Types and Data Type Utilities
7) Database Interfaces
8) User Interfaces
9) Interfaces to or Emulations of Other Programming Languages
10) File Names, File Systems and File Locking (see also File Handles)
11) String Processing, Language Text Processing, Parsing and Searching
12) Option, Argument, Parameter and Configuration File Processing
13) Internationalization and Locale
14) Authentication, Security and Encryption
15) World Wide Web, HTML, HTTP, CGI, MIME
16) Server and Daemon Utilities
17) Archiving, Compression and Conversion
18) Images, Pixmap and Bitmap Manipulation, Drawing and Graphing
19) Mail and Usenet News
20) Control Flow Utilities (callbacks and exceptions etc)
21) File Handle, Directory Handle and Input/Output Stream Utilities
22) Microsoft Windows Modules
23) Miscellaneous Modules
24) Interface Modules to Commercial Software
Part 3 - Big Projects Registry
1) Items in the Todo File
2) Multi-threading
3) Object Management Group CORBA & IDL
4) Expand Tied Array Interface
5) Extend Yacc To Write XS Code
6) Approximate Matching Regular Expressions
Part 4 - Standards Cross-reference
1) IETF - Internet Engineering Task Force (RFCs)
2) ITU - International Telegraph Union (X.*)
3) ISO - International Standards Organization (ISO*)
Part 5 - Who's Who and What's Where
1) Information / Contact Reference Details
2) Perl Frequently Asked Questions (FAQ) Files
3) Other Perl Archive Sites
Key: '+' indicates a new section or item,
'!' indicates a changed section or item (typically new modules).
======================================================================
Introduction
This document is a semi-formal list of Perl 5 Modules. The Perl 4
concept of packages has been extended in Perl 5 and a new standardised
form of reusable software component has been defined: the Module.
Perl 5 Modules typically conform to certain guidelines which make them
easier to use, reuse, integrate and extend.
This list will be posted to comp.lang.perl.announce and comp.answers on
a semi-regular basis. It has two key aims:
- FOR DEVELOPERS: To change duplication of effort into cooperation.
- FOR USERS: To quickly locate existing software which can be reused.
This list includes the Perl 5 standard modules, other completed
modules, work-in-progress modules and would-be-nice-to-have ideas for
modules. It also includes guidelines for those wishing to create new
modules including how to name them.
Where Are The Modules Kept?
Most, but not all, of the modules can be found within CPAN, the
Comprehensive Perl Archive Network of mirrored FTP sites. Within the
CPAN scheme the modules described in this list can be found in the
modules/ directory below the CPAN root directory. These are the
currently registered CPAN sites:
Africa
South Africa
ftp://ftp.is.co.za/programming/perl/CPAN/
ftp://ftpza.co.za/pub/mirrors/cpan/
Asia
Armenia
ftp://sunsite.aua.am/pub/CPAN/
China
ftp://freesoft.cei.gov.cn/pub/languages/perl/CPAN/
Hong Kong
ftp://ftp.hkstar.com/pub/CPAN/
Israel
ftp://bioinfo.weizmann.ac.il/pub/software/perl/CPAN/
Japan
ftp://ftp.dti.ad.jp/pub/lang/CPAN/
ftp://ftp.jaist.ac.jp/pub/lang/perl/CPAN/
ftp://ftp.lab.kdd.co.jp/lang/perl/CPAN/
ftp://mirror.nucba.ac.jp/mirror/Perl/
Singapore
ftp://ftp.nus.edu.sg/pub/unix/perl/CPAN/
South Korea
ftp://ftp.bora.net/pub/CPAN/
ftp://ftp.nuri.net/pub/CPAN/
Taiwan
ftp://ftp.wownet.net/pub2/PERL/
Thailand
ftp://ftp.cs.riubon.ac.th/pub/mirrors/CPAN/
ftp://ftp.nectec.or.th/pub/mirrors/CPAN/
Australasia
Australia
ftp://cpan.topend.com.au/pub/CPAN/
ftp://ftp.sage-au.org.au/pub/compilers/perl/CPAN/
ftp://mirror.aarnet.edu.au/pub/perl/CPAN/
New Zealand
ftp://ftp.auckland.ac.nz/pub/perl/CPAN/
ftp://sunsite.net.nz/pub/languages/perl/CPAN/
Central America
Costa Rica
ftp://ftp.ucr.ac.cr/pub/Unix/CPAN/
Europe
Austria
ftp://ftp.tuwien.ac.at/pub/languages/perl/CPAN/
Belgium
ftp://ftp.kulnet.kuleuven.ac.be/pub/mirror/CPAN/
Bulgaria
ftp://ftp.ntrl.net/pub/mirrors/CPAN/
Croatia
ftp://ftp.linux.hr/pub/CPAN/
Czech Republic
ftp://ftp.fi.muni.cz/pub/perl/
ftp://sunsite.mff.cuni.cz/Languages/Perl/CPAN/
Denmark
ftp://sunsite.auc.dk/pub/languages/perl/CPAN/
Estonia
ftp://ftp.ut.ee/pub/languages/perl/CPAN/
Finland
ftp://ftp.funet.fi/pub/languages/perl/CPAN/
France
ftp://ftp.lip6.fr/pub/perl/CPAN/
ftp://ftp.oleane.net/pub/mirrors/CPAN/
ftp://ftp.pasteur.fr/pub/computing/CPAN/
Germany
ftp://ftp.archive.de.uu.net/pub/CPAN/
ftp://ftp.gmd.de/packages/CPAN/
ftp://ftp.gwdg.de/pub/languages/perl/CPAN/
ftp://ftp.leo.org/pub/comp/programming/languages/script/perl/CPAN/
ftp://ftp.mpi-sb.mpg.de/pub/perl/CPAN/
ftp://ftp.rz.ruhr-uni-bochum.de/pub/CPAN/
ftp://ftp.uni-erlangen.de/pub/source/CPAN/
ftp://ftp.uni-hamburg.de/pub/soft/lang/perl/CPAN/
Greece
ftp://ftp.ntua.gr/pub/lang/perl/
Hungary
ftp://ftp.kfki.hu/pub/packages/perl/CPAN/
Ireland
ftp://sunsite.compapp.dcu.ie/pub/perl/
Italy
ftp://cis.uniRoma2.it/CPAN/
ftp://ftp.flashnet.it/pub/CPAN/
Netherlands
ftp://ftp.cs.ruu.nl/pub/PERL/CPAN/
ftp://ftp.EU.net/packages/cpan/
Norway
ftp://ftp.uit.no/pub/languages/perl/cpan/
ftp://sunsite.uio.no/pub/languages/perl/CPAN/
Poland
ftp://ftp.man.szczecin.pl/pub/perl/CPAN/
ftp://ftp.man.torun.pl/pub/CPAN/
ftp://ftp.pk.edu.pl/pub/lang/perl/CPAN/
ftp://sunsite.icm.edu.pl/pub/CPAN/
Portugal
ftp://ftp.ci.uminho.pt/pub/lang/perl/
ftp://ftp.ua.pt/pub/CPAN/
Romania
ftp://ftp.dntis.ro/pub/mirrors/perl-cpan/
ftp://ftp.dnttm.ro/pub/CPAN/
Russia
ftp://cpan.npi.msu.su/CPAN/
ftp://ftp.sai.msu.su/pub/lang/perl/CPAN/
Slovakia
ftp://ftp.entry.sk/pub/languages/perl/CPAN/
Slovenia
ftp://ftp.arnes.si/software/perl/CPAN/
Spain
ftp://ftp.etse.urv.es/pub/perl/
ftp://ftp.rediris.es/mirror/CPAN/
Sweden
ftp://ftp.sunet.se/pub/lang/perl/CPAN/
Switzerland
ftp://sunsite.cnlab-switch.ch/mirror/CPAN/
Turkeya
ftp://sunsite.bilkent.edu.tr/pub/languages/CPAN/
United Kingdom
ftp://ftp.demon.co.uk/pub/mirrors/perl/CPAN/
ftp://ftp.flirble.org/pub/languages/perl/CPAN/
ftp://ftp.plig.org/pub/CPAN/
ftp://sunsite.doc.ic.ac.uk/packages/CPAN/
ftp://unix.hensa.ac.uk/mirrors/perl-CPAN/
North America
Canada
ftp://ftp.crc.ca/pub/packages/perl/CPAN/
ftp://theory.uwinnipeg.ca/pub/CPAN/
United States
ftp://cpan.if.usp.br/pub/mirror/CPAN/
ftp://ftp.ccs.neu.edu/net/mirrors/ftp.funet.fi/pub/languages/perl/CPAN/
ftp://ftp.cdrom.com/pub/perl/CPAN/
ftp://ftp.cise.ufl.edu/pub/perl/CPAN/
ftp://ftp.cs.colorado.edu/pub/perl/CPAN/
ftp://ftp.digital.com/pub/plan/perl/CPAN/
ftp://ftp.duke.edu/pub/perl/
ftp://ftp.epix.net/pub/languages/perl/
ftp://ftp.iguide.com/pub/mirrors/packages/perl/CPAN/
ftp://ftp.metronet.com/pub/perl/
ftp://ftp.orst.edu/pub/packages/CPAN/
ftp://ftp.ou.edu/mirrors/CPAN/
ftp://ftp.rge.com/pub/languages/perl/
ftp://ftp.sedl.org/pub/mirrors/CPAN/
ftp://ftp.spu.edu/pub/CPAN/
ftp://ftp.uwsg.indiana.edu/pub/perl/CPAN/
ftp://uiarchive.uiuc.edu/pub/lang/perl/CPAN/
South America
Brazil
ftp://ftp.ing.puc.cl/pub/unix/perl/CPAN/
Chile
ftp://sunsite.dcc.uchile.cl/pub/Lang/perl/CPAN/
All the files under each of the directories listed above should be
identical at all these sites since they are all automatically
maintained mirrors of the master CPAN site. Please use which ever site
is 'nearest' you.
NOTE: If you can't find what you want, or wish to check that what
you've found is the latest version, or wonder why a module mentioned in
this list is not on CPAN, you should contact the person associated with
the module (and not the maintainers of the archives or this list).
Contact details are given at the start of Part 5.
Playing Your Part
Perl is a huge collaborative effort. Everyone who uses perl is
benefiting from the contributions of many hundreds, maybe thousands, of
people. How much time has perl saved you since you started using it?
Do you have any modules you could share with others? For example, you
may have some perl4 scripts from which generally useful, and reusable,
modules could be extracted. There may be many people who would find
your work very useful. Please play your part and contribute to the Perl
community where you can. [ end of sermon :-]
Help save the world! Please submit new entries and updates to us so we
can keep this list up-to-date. Send the new or corrected entry by email
to modules@perl.org (or modules@franz.ww.tu-berlin.de in case the above
doesn't work). Please do not send code to this address. Instead upload
your module, once registered, to the PAUSE site for forwarding on to
CPAN. See section 2, especially 2.6 and 2.11.
How To Get a More Recent Copy of the List
This Module List is posted to comp.lang.perl.modules, comp.answers and
news.answers bi-weekly with a long expiry time (over a month). The
first place to look for a more recent copy is therefore your own Usenet
spool area.
You should be able to get a copy from one of these places:
Editorial Information and Copyright
This document is Copyright (c) 1997 by Tim Bunce and Andreas König. All
rights reserved. Permission to distribute this document, in full or
part, via electronic means (emailed, posted or archived) or printed
copy is granted providing that no charges are involved, reasonable
attempt is made to use the most current version, and all credits and
copyright notices are retained. Requests for other distribution rights,
including incorporation in commercial products, such as books, magazine
articles, or CD-ROMs should be made to Tim.Bunce@ig.co.uk and
Andreas.Koenig@mind.de.
Disclaimer: The content of this document is simply a collection of
information gathered from many sources with little or no checking.
There are NO warranties with regard to this information or its use.
======================================================================
Part 1 - Modules: Creation, Use and Abuse
=========================================
1) Perl 5 Module Terminology
-------------------------
Perl 5 implements a class using a package, but the presence of a
package doesn't imply the presence of a class. A package is just a
namespace. A class is a package that provides subroutines that can be
used as methods. A method is just a subroutine that expects, as its
first argument, either the name of a package (for "static" methods), or
a reference to something (for "virtual" methods).
A module is a file that (by convention) provides a class of the same
name (sans the .pm), plus an import method in that class that can be
called to fetch exported symbols. This module may implement some of its
methods by loading dynamic C or C++ objects, but that should be totally
transparent to the user of the module. Likewise, the module might set
up an AUTOLOAD function to slurp in subroutine definitions on demand,
but this is also transparent. Only the .pm file is required to exist.
2) Guidelines for Module Creation
------------------------------
2.1 Do similar modules already exist in some form?
If so, please try to reuse the existing modules either in whole or
by inheriting useful features into a new class. If this is not
practical try to get together with the module authors to work on
extending or enhancing the functionality of the existing modules.
A perfect example is the plethora of packages in perl4 for dealing
with command line options.
If you are writing a module to expand an already existing set of
modules, please coordinate with the author of the package. It
helps if you follow the same naming scheme and module interaction
scheme as the original author.
2.2 Try to design the new module to be easy to extend and reuse.
Use blessed references. Use the two argument form of bless to bless
into the class name given as the first parameter of the constructor,
e.g.:
sub new {
my $class = shift;
return bless {}, $class;
}
or even this if you'd like it to be used as either a static
or a virtual method.
sub new {
my $self = shift;
my $class = ref($self) || $self;
return bless {}, $class;
}
Pass arrays as references so more parameters can be added later
(it's also faster). Convert functions into methods where
appropriate. Split large methods into smaller more flexible ones.
Inherit methods from other modules if appropriate.
Avoid class name tests like: die "Invalid" unless ref $ref eq 'FOO'.
Generally you can delete the "eq 'FOO'" part with no harm at all.
Let the objects look after themselves! If it's vital then you can
use the UNIVERSAL methods isa and can. Generally, avoid hardwired
class names as far as possible.
Avoid $r->Class::func() where using @ISA=qw(... Class ...) and
$r->func() would work (see perlbot man page for more details).
Use autosplit or the SelfLoader module so little used or newly added
functions won't be a burden to programs which don't use them. Add
test functions to the module after __END__ either using autosplit or
by saying:
eval join('',) || die $@ unless caller();
Does your module pass the 'empty sub-class' test? If you say
"@SUBCLASS::ISA = qw(YOURCLASS);" your applications should be able
to use SUBCLASS in exactly the same way as YOURCLASS. For example,
does your application still work if you change: $obj = new YOURCLASS;
into: $obj = new SUBCLASS; ?
Avoid keeping any state information in your packages. It makes it
difficult for multiple other packages to use yours. Keep state
information in objects.
Always use -w. Try to "use strict;" (or "use strict qw(...);").
Remember that you can add "no strict qw(...);" to individual blocks
of code which need less strictness. Always use -w. Always use -w!
Follow the guidelines in the perlstyle(1) manual.
2.3 Some simple style guidelines
The perlstyle manual supplied with perl has many helpful points.
Coding style is a matter of personal taste. Many people evolve their
style over several years as they learn what helps them write and
maintain good code. Here's one set of assorted suggestions that
seem to be widely used by experienced developers:
Use underscores to separate words. It is generally easier to read
$var_names_like_this than $VarNamesLikeThis, especially for
non-native speakers of English. It's also a simple rule that works
consistently with VAR_NAMES_LIKE_THIS.
Package/Module names are an exception to this rule. Perl informally
reserves lowercase module names for 'pragma' modules like integer
and strict. Other modules normally begin with a capital letter and
use mixed case with no underscores (need to be short and portable).
You may find it helpful to use letter case to indicate the scope
or nature of a variable. For example:
$ALL_CAPS_HERE constants only (beware clashes with perl vars)
$Some_Caps_Here package-wide global/static
$no_caps_here function scope my() or local() variables
Function and method names seem to work best as all lowercase.
E.g., $obj->as_string().
You can use a leading underscore to indicate that a variable or
function should not be used outside the package that defined it.
For method calls use either
$foo = new Foo $arg1, $arg2; # no parentheses
$foo = Foo->new($arg1, $arg2);
but avoid the ambiguous form
$foo = new Foo($arg1, $arg2); # Foo() looks like function call
It can be very helpful if the names of the classes that your module
uses can be specified as parameters. Consider:
$dog_class = $args{dog_class} || 'Dog';
$spot = $dog_class->new(...);
This allows the user of your module to specify an alternative class
(typically a subclass of the one you would normally have used).
On how to report constructor failure, Larry said:
I tend to see it as exceptional enough that I'll throw a real Perl
exception (die) if I can't construct an object. This has a couple
of advantages right off the bat. First, you don't have to check the
return value of every constructor. Just say "$fido = new Doggie;"
and presume it succeeded. This leads to clearer code in most cases.
Second, if it does fail, you get a better diagnostic than just the
undefinedness of the return value. In fact, the exception it throws
may be quite rich in "stacked" error messages, if it's rethrowing an
exception caught further in.
And you can always catch the exception if it does happen using eval {}.
If, on the other hand, you expect your constructor to fail a goodly
part of the time, then you shouldn't use exceptions, but you should
document the interface so that people will know to check the return
value. You don't need to use defined(), since a constructor would
only return a true reference or a false undef. So good Perl style
for checking a return value would simply say
$conn = new Connection $addr
or die "Couldn't create Connection";
In general, make as many things meaningful in a Boolean context as
you can. This leads to straightforward code. Never write anything
like
if (do_your_thing() == OK)
in Perl. That's just asking for logic errors and domain errors.
Just write
if (do_your_thing())
Perl is designed to help you eschew obfuscation, if that's your thing.
2.4 Select what to export.
Do NOT export method names!
Do NOT export anything else by default without a good reason!
Exports pollute the namespace of the module user. If you must
export try to use @EXPORT_OK in preference to @EXPORT and avoid
short or common names to reduce the risk of name clashes.
Generally anything not exported is still accessible from outside the
module using the ModuleName::item_name (or $blessed_ref->method)
syntax. By convention you can use a leading underscore on names to
informally indicate that they are 'internal' and not for public use.
(It is actually possible to get private functions by saying:
my $subref = sub { ... }; &$subref; But there's no way to call that
directly as a method, since a method must have a name in the symbol
table.)
As a general rule, if the module is trying to be object oriented
then export nothing. If it's just a collection of functions then
@EXPORT_OK anything but use @EXPORT with caution.
2.5 Select a name for the module.
This name should be as descriptive, accurate and complete as
possible. Avoid any risk of ambiguity. Always try to use two or
more whole words. Generally the name should reflect what is special
about what the module does rather than how it does it.
Having 57 modules all called Sort will not make life easy for anyone
(though having 23 called Sort::Quick is only marginally better :-).
Imagine someone trying to install your module alongside many others.
If in any doubt ask for suggestions in comp.lang.perl.modules or
modules@perl.org.
Please use a nested module name to informally group or categorise
a module, e.g., placing a sorting module into a Sort:: category.
A module should have a very good reason not to have a nested name.
Please avoid using more than one level of nesting for module names
(packages or classes within modules can, of course, use any number).
Module names should begin with a capital letter. Lowercase names are
reserved for special modules such as pragmas (e.g., lib and strict).
Note that module names are not related to class hierarchies.
A module name Foo::Bar does not in any way imply that Foo::Bar
inherits from Foo. Nested names are simply used to provide some
useful categorisation for humans. The same is generally true for
all package names.
Since the CPAN is huge and growing daily, it's essential that
module authors choose names which lend themselves to browsing.
That means minimizing acronyms, cute names, and jargon. Also,
don't make up a new top level category unless you have a good
reason; please choose an already-existing category when
possible. Send mail to modules@perl.org before you upload, so
we can help you select a name.
If you insist on a name that we consider inappropriate, we
won't prevent you from uploading your module -- but it'll
remain in your "author" directory and won't be directly visible
from CPAN/modules/by-module.
We appreciate the efforts of the contributors who have helped
make the CPAN the world's largest reusable code repository.
Please help us enhance it by working with us to choose the
best name possible.
If you are developing a suite of related modules/classes it's good
practice to use nested classes with a common prefix as this will
avoid namespace clashes. For example: Xyz::Control, Xyz::View,
Xyz::Model etc. Use the modules in this list as a naming guide.
If adding a new module to a set, follow the original author's
standards for naming modules and the interface to methods in
those modules.
If developing modules for private internal or project specific use,
that will never be released to the public, then you should ensure
that their names will not clash with any future public module. You
can do this either by using the reserved Local::* category or by
using a category name that includes an underscore like Foo_Corp::*.
To be portable each component of a module name should be limited to
11 characters. If it might be used on DOS then try to ensure each is
unique in the first 8 characters. Nested modules make this easier.
2.6 Have you got it right?
How do you know that you've made the right decisions? Have you
picked an interface design that will cause problems later? Have
you picked the most appropriate name? Do you have any questions?
The best way to know for sure, and pick up many helpful suggestions,
is to ask someone who knows. The comp.lang.perl.modules Usenet
newsgroup is read by just about all the people who develop modules
and it's generally the best place to ask first. If you need more
help then try modules@perl.org.
All you need to do is post a short summary of the module, its
purpose and interfaces. A few lines on each of the main methods is
probably enough. (If you post the whole module it might be ignored
by busy people - generally the very people you want to read it!)
Don't worry about posting if you can't say when the module will be
ready - just say so in the message. It might be worth inviting
others to help you, they may be able to complete it for you!
2.7 README and other Additional Files.
It's well known that software developers usually fully document the
software they write. If, however, the world is in urgent need of
your software and there is not enough time to write the full
documentation please at least provide a README file containing:
- A description of the module/package/extension etc.
- A copyright notice - see below.
- Prerequisites - what else you may need to have.
- How to build it - possible changes to Makefile.PL etc.
- How to install it.
- Recent changes in this release, especially incompatibilities
- Changes / enhancements you plan to make in the future.
If the README file seems to be getting too large you may wish to
split out some of the sections into separate files: INSTALL,
Copying, ToDo etc.
2.8 Adding a Copyright Notice.
How you choose to licence your work is a personal decision.
The general mechanism is to assert your Copyright and then make
a declaration of how others may copy/use/modify your work.
Perl, for example, is supplied with two types of licence: The GNU
GPL and The Artistic License (see the files README, Copying and
Artistic). Larry has good reasons for NOT just using the GNU GPL.
My personal recommendation, out of respect for Larry, Perl and the
perl community at large is to simply state something like:
Copyright (c) 1997 Your Name. All rights reserved.
This program is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
This statement should at least appear in the README file. You may
also wish to include it in a Copying file and your source files.
Remember to include the other words in addition to the Copyright.
2.9 Give the module a version/issue/release number.
To be fully compatible with the Exporter and MakeMaker modules you
should store your module's version number in a non-my package
variable called $VERSION. This should be a valid floating point
number with at least two digits after the decimal (ie hundredths,
e.g, $VERSION = "0.01"). See Exporter.pm for details.
Don't use a "1.3.2" style version directly. If you use RCS or a
similar system which supports multilevel versions/branches you can
use this (but put it all on one line for MakeMaker VERSION_FROM):
$VERSION = do { my @r=(q$Revision: 2.99 $=~/\d+/g);
sprintf "%d."."%02d"x$#r,@r };
It may be handy to add a function or method to retrieve the number.
Use the number in announcements and archive file names when
releasing the module (ModuleName-1.02.tar.gz).
See perldoc ExtUtils::MakeMaker.pm for details.
2.10 Listing Prerequisites in a Bundle module
If your module needs some others that are available on CPAN, you
might consider creating a 'bundle' module that lists all the
prerequisites in a standardized way. Automatic installation software
such as the CPAN.pm module can take advantage of such a listing and
enable your users to install all prerequisites and your own module
with one single command. See the CPAN.pm module for details.
2.11 How to release and distribute a module.
By far the best way to release modules is to register yourself with
the Perl Authors Upload Server (PAUSE). By registering with PAUSE
you will be able to easily upload (or mirror) your modules to the
PAUSE server from where they will be mirrored to CPAN sites across
the planet.
It's good idea to post an announcement of the availability of your
module to the comp.lang.perl.announce Usenet newsgroup. This will
at least ensure very wide once-off distribution.
If not using PAUSE you should place the module into a major ftp
archive and include details of it's location in your announcement.
Some notes about ftp archives: Please use a long descriptive file
name which includes the version number. Most incoming directories
will not be readable/listable, i.e., you won't be able to see your
file after uploading it. Remember to send your email notification
message as soon as possible after uploading else your file may get
deleted automatically. Allow time for the file to be processed
and/or check the file has been processed before announcing its
location.
FTP Archives for Perl Modules:
Follow the instructions and links on
or upload to one of these sites:
and notify upload@pause.kbx.de.
By using the PAUSE WWW interface you can ask the Upload Server to
mirror your modules from your ftp or WWW site into your own
directory on CPAN. Please remember to send us an updated entry for
the Module list!
2.12 Take care when changing a released module.
Always strive to remain compatible with previous released versions
(see 2.2 above) Otherwise try to add a mechanism to revert to the
old behaviour if people rely on it. Document incompatible changes.
3) Guidelines for Converting Perl 4 Library Scripts into Modules
-------------------------------------------------------------
3.1 There is no requirement to convert anything.
If it ain't broke, don't fix it! Perl 4 library scripts should
continue to work with no problems. You may need to make some minor
changes (like escaping non-array @'s in double quoted strings) but
there is no need to convert a .pl file into a Module for just that.
See perltrap.pod for details of all known perl4-to-perl5 issues.
3.2 Consider the implications.
All the perl applications which make use of the script will need to
be changed (slightly) if the script is converted into a module. Is
it worth it unless you plan to make other changes at the same time?
Section 1 of 5 - Prev - Next All sections - 1 - 2 - 3 - 4 - 5
