1 | =head1 NAME
|
---|
2 |
|
---|
3 | perlnewmod - preparing a new module for distribution
|
---|
4 |
|
---|
5 | =head1 DESCRIPTION
|
---|
6 |
|
---|
7 | This document gives you some suggestions about how to go about writing
|
---|
8 | Perl modules, preparing them for distribution, and making them available
|
---|
9 | via CPAN.
|
---|
10 |
|
---|
11 | One of the things that makes Perl really powerful is the fact that Perl
|
---|
12 | hackers tend to want to share the solutions to problems they've faced,
|
---|
13 | so you and I don't have to battle with the same problem again.
|
---|
14 |
|
---|
15 | The main way they do this is by abstracting the solution into a Perl
|
---|
16 | module. If you don't know what one of these is, the rest of this
|
---|
17 | document isn't going to be much use to you. You're also missing out on
|
---|
18 | an awful lot of useful code; consider having a look at L<perlmod>,
|
---|
19 | L<perlmodlib> and L<perlmodinstall> before coming back here.
|
---|
20 |
|
---|
21 | When you've found that there isn't a module available for what you're
|
---|
22 | trying to do, and you've had to write the code yourself, consider
|
---|
23 | packaging up the solution into a module and uploading it to CPAN so that
|
---|
24 | others can benefit.
|
---|
25 |
|
---|
26 | =head2 Warning
|
---|
27 |
|
---|
28 | We're going to primarily concentrate on Perl-only modules here, rather
|
---|
29 | than XS modules. XS modules serve a rather different purpose, and
|
---|
30 | you should consider different things before distributing them - the
|
---|
31 | popularity of the library you are gluing, the portability to other
|
---|
32 | operating systems, and so on. However, the notes on preparing the Perl
|
---|
33 | side of the module and packaging and distributing it will apply equally
|
---|
34 | well to an XS module as a pure-Perl one.
|
---|
35 |
|
---|
36 | =head2 What should I make into a module?
|
---|
37 |
|
---|
38 | You should make a module out of any code that you think is going to be
|
---|
39 | useful to others. Anything that's likely to fill a hole in the communal
|
---|
40 | library and which someone else can slot directly into their program. Any
|
---|
41 | part of your code which you can isolate and extract and plug into
|
---|
42 | something else is a likely candidate.
|
---|
43 |
|
---|
44 | Let's take an example. Suppose you're reading in data from a local
|
---|
45 | format into a hash-of-hashes in Perl, turning that into a tree, walking
|
---|
46 | the tree and then piping each node to an Acme Transmogrifier Server.
|
---|
47 |
|
---|
48 | Now, quite a few people have the Acme Transmogrifier, and you've had to
|
---|
49 | write something to talk the protocol from scratch - you'd almost
|
---|
50 | certainly want to make that into a module. The level at which you pitch
|
---|
51 | it is up to you: you might want protocol-level modules analogous to
|
---|
52 | L<Net::SMTP|Net::SMTP> which then talk to higher level modules analogous
|
---|
53 | to L<Mail::Send|Mail::Send>. The choice is yours, but you do want to get
|
---|
54 | a module out for that server protocol.
|
---|
55 |
|
---|
56 | Nobody else on the planet is going to talk your local data format, so we
|
---|
57 | can ignore that. But what about the thing in the middle? Building tree
|
---|
58 | structures from Perl variables and then traversing them is a nice,
|
---|
59 | general problem, and if nobody's already written a module that does
|
---|
60 | that, you might want to modularise that code too.
|
---|
61 |
|
---|
62 | So hopefully you've now got a few ideas about what's good to modularise.
|
---|
63 | Let's now see how it's done.
|
---|
64 |
|
---|
65 | =head2 Step-by-step: Preparing the ground
|
---|
66 |
|
---|
67 | Before we even start scraping out the code, there are a few things we'll
|
---|
68 | want to do in advance.
|
---|
69 |
|
---|
70 | =over 3
|
---|
71 |
|
---|
72 | =item Look around
|
---|
73 |
|
---|
74 | Dig into a bunch of modules to see how they're written. I'd suggest
|
---|
75 | starting with L<Text::Tabs|Text::Tabs>, since it's in the standard
|
---|
76 | library and is nice and simple, and then looking at something a little
|
---|
77 | more complex like L<File::Copy|File::Copy>. For object oriented
|
---|
78 | code, C<WWW::Mechanize> or the C<Email::*> modules provide some good
|
---|
79 | examples.
|
---|
80 |
|
---|
81 | These should give you an overall feel for how modules are laid out and
|
---|
82 | written.
|
---|
83 |
|
---|
84 | =item Check it's new
|
---|
85 |
|
---|
86 | There are a lot of modules on CPAN, and it's easy to miss one that's
|
---|
87 | similar to what you're planning on contributing. Have a good plough
|
---|
88 | through the L<http://search.cpan.org> and make sure you're not the one
|
---|
89 | reinventing the wheel!
|
---|
90 |
|
---|
91 | =item Discuss the need
|
---|
92 |
|
---|
93 | You might love it. You might feel that everyone else needs it. But there
|
---|
94 | might not actually be any real demand for it out there. If you're unsure
|
---|
95 | about the demand your module will have, consider sending out feelers
|
---|
96 | on the C<comp.lang.perl.modules> newsgroup, or as a last resort, ask the
|
---|
97 | modules list at C<[email protected]>. Remember that this is a closed list
|
---|
98 | with a very long turn-around time - be prepared to wait a good while for
|
---|
99 | a response from them.
|
---|
100 |
|
---|
101 | =item Choose a name
|
---|
102 |
|
---|
103 | Perl modules included on CPAN have a naming hierarchy you should try to
|
---|
104 | fit in with. See L<perlmodlib> for more details on how this works, and
|
---|
105 | browse around CPAN and the modules list to get a feel of it. At the very
|
---|
106 | least, remember this: modules should be title capitalised, (This::Thing)
|
---|
107 | fit in with a category, and explain their purpose succinctly.
|
---|
108 |
|
---|
109 | =item Check again
|
---|
110 |
|
---|
111 | While you're doing that, make really sure you haven't missed a module
|
---|
112 | similar to the one you're about to write.
|
---|
113 |
|
---|
114 | When you've got your name sorted out and you're sure that your module is
|
---|
115 | wanted and not currently available, it's time to start coding.
|
---|
116 |
|
---|
117 | =back
|
---|
118 |
|
---|
119 | =head2 Step-by-step: Making the module
|
---|
120 |
|
---|
121 | =over 3
|
---|
122 |
|
---|
123 | =item Start with F<module-starter> or F<h2xs>
|
---|
124 |
|
---|
125 | The F<module-starter> utility is distributed as part of the
|
---|
126 | L<Module::Starter|Module::Starter> CPAN package. It creates a directory
|
---|
127 | with stubs of all the necessary files to start a new module, according
|
---|
128 | to recent "best practice" for module development, and is invoked from
|
---|
129 | the command line, thus:
|
---|
130 |
|
---|
131 | module-starter --module=Foo::Bar \
|
---|
132 | --author="Your Name" [email protected]
|
---|
133 |
|
---|
134 | If you do not wish to install the L<Module::Starter|Module::Starter>
|
---|
135 | package from CPAN, F<h2xs> is an older tool, originally intended for the
|
---|
136 | development of XS modules, which comes packaged with the Perl
|
---|
137 | distribution.
|
---|
138 |
|
---|
139 | A typical invocation of L<h2xs|h2xs> for a pure Perl module is:
|
---|
140 |
|
---|
141 | h2xs -AX --skip-exporter --use-new-tests -n Foo::Bar
|
---|
142 |
|
---|
143 | The C<-A> omits the Autoloader code, C<-X> omits XS elements,
|
---|
144 | C<--skip-exporter> omits the Exporter code, C<--use-new-tests> sets up a
|
---|
145 | modern testing environment, and C<-n> specifies the name of the module.
|
---|
146 |
|
---|
147 | =item Use L<strict|strict> and L<warnings|warnings>
|
---|
148 |
|
---|
149 | A module's code has to be warning and strict-clean, since you can't
|
---|
150 | guarantee the conditions that it'll be used under. Besides, you wouldn't
|
---|
151 | want to distribute code that wasn't warning or strict-clean anyway,
|
---|
152 | right?
|
---|
153 |
|
---|
154 | =item Use L<Carp|Carp>
|
---|
155 |
|
---|
156 | The L<Carp|Carp> module allows you to present your error messages from
|
---|
157 | the caller's perspective; this gives you a way to signal a problem with
|
---|
158 | the caller and not your module. For instance, if you say this:
|
---|
159 |
|
---|
160 | warn "No hostname given";
|
---|
161 |
|
---|
162 | the user will see something like this:
|
---|
163 |
|
---|
164 | No hostname given at /usr/local/lib/perl5/site_perl/5.6.0/Net/Acme.pm
|
---|
165 | line 123.
|
---|
166 |
|
---|
167 | which looks like your module is doing something wrong. Instead, you want
|
---|
168 | to put the blame on the user, and say this:
|
---|
169 |
|
---|
170 | No hostname given at bad_code, line 10.
|
---|
171 |
|
---|
172 | You do this by using L<Carp|Carp> and replacing your C<warn>s with
|
---|
173 | C<carp>s. If you need to C<die>, say C<croak> instead. However, keep
|
---|
174 | C<warn> and C<die> in place for your sanity checks - where it really is
|
---|
175 | your module at fault.
|
---|
176 |
|
---|
177 | =item Use L<Exporter|Exporter> - wisely!
|
---|
178 |
|
---|
179 | L<Exporter|Exporter> gives you a standard way of exporting symbols and
|
---|
180 | subroutines from your module into the caller's namespace. For instance,
|
---|
181 | saying C<use Net::Acme qw(&frob)> would import the C<frob> subroutine.
|
---|
182 |
|
---|
183 | The package variable C<@EXPORT> will determine which symbols will get
|
---|
184 | exported when the caller simply says C<use Net::Acme> - you will hardly
|
---|
185 | ever want to put anything in there. C<@EXPORT_OK>, on the other hand,
|
---|
186 | specifies which symbols you're willing to export. If you do want to
|
---|
187 | export a bunch of symbols, use the C<%EXPORT_TAGS> and define a standard
|
---|
188 | export set - look at L<Exporter> for more details.
|
---|
189 |
|
---|
190 | =item Use L<plain old documentation|perlpod>
|
---|
191 |
|
---|
192 | The work isn't over until the paperwork is done, and you're going to
|
---|
193 | need to put in some time writing some documentation for your module.
|
---|
194 | C<module-starter> or C<h2xs> will provide a stub for you to fill in; if
|
---|
195 | you're not sure about the format, look at L<perlpod> for an
|
---|
196 | introduction. Provide a good synopsis of how your module is used in
|
---|
197 | code, a description, and then notes on the syntax and function of the
|
---|
198 | individual subroutines or methods. Use Perl comments for developer notes
|
---|
199 | and POD for end-user notes.
|
---|
200 |
|
---|
201 | =item Write tests
|
---|
202 |
|
---|
203 | You're encouraged to create self-tests for your module to ensure it's
|
---|
204 | working as intended on the myriad platforms Perl supports; if you upload
|
---|
205 | your module to CPAN, a host of testers will build your module and send
|
---|
206 | you the results of the tests. Again, C<module-starter> and C<h2xs>
|
---|
207 | provide a test framework which you can extend - you should do something
|
---|
208 | more than just checking your module will compile.
|
---|
209 | L<Test::Simple|Test::Simple> and L<Test::More|Test::More> are good
|
---|
210 | places to start when writing a test suite.
|
---|
211 |
|
---|
212 | =item Write the README
|
---|
213 |
|
---|
214 | If you're uploading to CPAN, the automated gremlins will extract the
|
---|
215 | README file and place that in your CPAN directory. It'll also appear in
|
---|
216 | the main F<by-module> and F<by-category> directories if you make it onto
|
---|
217 | the modules list. It's a good idea to put here what the module actually
|
---|
218 | does in detail, and the user-visible changes since the last release.
|
---|
219 |
|
---|
220 | =back
|
---|
221 |
|
---|
222 | =head2 Step-by-step: Distributing your module
|
---|
223 |
|
---|
224 | =over 3
|
---|
225 |
|
---|
226 | =item Get a CPAN user ID
|
---|
227 |
|
---|
228 | Every developer publishing modules on CPAN needs a CPAN ID. Visit
|
---|
229 | C<http://pause.perl.org/>, select "Request PAUSE Account", and wait for
|
---|
230 | your request to be approved by the PAUSE administrators.
|
---|
231 |
|
---|
232 | =item C<perl Makefile.PL; make test; make dist>
|
---|
233 |
|
---|
234 | Once again, C<module-starter> or C<h2xs> has done all the work for you.
|
---|
235 | They produce the standard C<Makefile.PL> you see when you download and
|
---|
236 | install modules, and this produces a Makefile with a C<dist> target.
|
---|
237 |
|
---|
238 | Once you've ensured that your module passes its own tests - always a
|
---|
239 | good thing to make sure - you can C<make dist>, and the Makefile will
|
---|
240 | hopefully produce you a nice tarball of your module, ready for upload.
|
---|
241 |
|
---|
242 | =item Upload the tarball
|
---|
243 |
|
---|
244 | The email you got when you received your CPAN ID will tell you how to
|
---|
245 | log in to PAUSE, the Perl Authors Upload SErver. From the menus there,
|
---|
246 | you can upload your module to CPAN.
|
---|
247 |
|
---|
248 | =item Announce to the modules list
|
---|
249 |
|
---|
250 | Once uploaded, it'll sit unnoticed in your author directory. If you want
|
---|
251 | it connected to the rest of the CPAN, you'll need to go to "Register
|
---|
252 | Namespace" on PAUSE. Once registered, your module will appear in the
|
---|
253 | by-module and by-category listings on CPAN.
|
---|
254 |
|
---|
255 | =item Announce to clpa
|
---|
256 |
|
---|
257 | If you have a burning desire to tell the world about your release, post
|
---|
258 | an announcement to the moderated C<comp.lang.perl.announce> newsgroup.
|
---|
259 |
|
---|
260 | =item Fix bugs!
|
---|
261 |
|
---|
262 | Once you start accumulating users, they'll send you bug reports. If
|
---|
263 | you're lucky, they'll even send you patches. Welcome to the joys of
|
---|
264 | maintaining a software project...
|
---|
265 |
|
---|
266 | =back
|
---|
267 |
|
---|
268 | =head1 AUTHOR
|
---|
269 |
|
---|
270 | Simon Cozens, C<[email protected]>
|
---|
271 |
|
---|
272 | Updated by Kirrily "Skud" Robert, C<[email protected]>
|
---|
273 |
|
---|
274 | =head1 SEE ALSO
|
---|
275 |
|
---|
276 | L<perlmod>, L<perlmodlib>, L<perlmodinstall>, L<h2xs>, L<strict>,
|
---|
277 | L<Carp>, L<Exporter>, L<perlpod>, L<Test::Simple>, L<Test::More>
|
---|
278 | L<ExtUtils::MakeMaker>, L<Module::Build>, L<Module::Starter>
|
---|
279 | http://www.cpan.org/ , Ken Williams' tutorial on building your own
|
---|
280 | module at http://mathforum.org/~ken/perl_modules.html
|
---|