| 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<modules@perl.org>. 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=yourname@cpan.org |
| 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<simon@cpan.org> |
| 271 | |
| 272 | Updated by Kirrily "Skud" Robert, C<skud@cpan.org> |
| 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 |