Writing Perl Modules for CPAN 63
| Writing Perl Modules for CPAN | |
| author | Sam Tregar |
| pages | 288 |
| publisher | Apress |
| rating | Recommended. |
| reviewer | chromatic |
| ISBN | 159059018X |
| summary | A guide to the use and production of Perl modules, from start to finish, in C and in Perl. |
The Scoop
Besides Perl's abilities as a rapid development language, it's widely believed that the CPAN is its most valuable feature. This network of freely distributable code allows competent developers to achieve great heights of productivity, reusing the work of a generous community of programmers.
Of course, just as some will argue that Perl's copious documentation (spread over two thousand pages) is not immediately obvious to beginners, neither is how to use and even to contribute to the CPAN. For every coder who's successfully published a module, how many more would jump at the chance? How many registered CPAN authors would like to improve their skills?
With that audience in mind, Sam Tregar's Writing Perl Modules for CPAN plants itself firmly in the gap between novice and intermediate user. While much of the book presents information present in a multitude of FAQs, manpages, and the bittersweet experiences of those of us who did things the hard way, he's collected much knowledge into a short and readable guide.
What's to Like?
Tregar starts by describing the history and usage of the CPAN itself. This includes the three most popular approaches to building modules: through the CPAN shell (including its configuration), by hand, and with ActiveState's PPM tool. Next, he explains module development in forty pages. This is pretty dense stuff for the intended audience and might require several passes by newer coders. Only after re-reviewing the chapter for this summary did I realize how much he covered. The next chapter covers design and style, from naming schemes to appropriate laziness through code reuse. It's more philosophical and more important.
The next two chapters cover bundling and submitting modules to the CPAN, as well as being a good author and maintainer. The general tone is quite similar to the impressive Open Source Development with CVS. While manpages usually describe the mechanics of making a distribution, for example, they rarely explain the reasons why things are done that way. As with previous chapters, several code examples illustrate the concepts under discussion.
After a brief chapter discussing a few very effective CPAN modules, Tregar dives into XS (the interface between Perl and C). In 60 pages, he describes just enough of XS and the Perl API to teach careful programmers how to be effective at extending Perl. This introduction compares favorably to the first few chapters of the new (and excellent) Extending and Embedding Perl. As expected in an overview, he provides links to more information. The writing and example style is clear enough that a decent coder with sufficient C knowledge should be able to write a Perl wrapper to a C library with relative ease.
The last two chapters describe Inline::C, an abstraction layer that makes XS much easier, and CGI::ApplicationC, a state machine framework for Perl CGI applications. It's not quite clear why the last chapter was included (besides Tregar's desire to see more CPAN modules extending CGI::Application), but it serves as an example of using and extending a CPAN module. Perhaps a future version of the book will elaborate further.
What's to Consider
The book's code samples are generally good. In the first half, they are all related parts of a larger project. The rest of the book moves away from this approach. Perhaps it would have been worthwhile to continue the theme, though the nature of the material makes it difficult to see exactly how to accomplish this.
Tregar also avoids the use of strictures and warnings in his code examples, claiming that they would make the examples too verbose. I disagree with the given reasoning -- teaching is the best time to enforce good habits, especially when encouraging the students to distribute their code to the world. This is a minor issue, though, as the code is readable and reasonable.
In the past few months, two projects have gained a great deal of momentum in Perl space. These are the CPANPLUS (disclaimer: I am contributing to this project and have contributed to CPAN.pm) and Module::Build. They may become the new standards, replacing CPAN.pm and MakeMaker as early as Perl 5.10. The book omits mention of these. This is understandable, given the time frame -- and the current tools will not be disappearing any time soon. Potential replacements for h2xs are described in a sidebar, though.
The Summary
This is a readable book. It took only a couple of hours to read (though I'm assuredly not the target audience), and is well packed with good advice. Fresher Perl programmers who aren't yet comfortable enough with packages and interfaces will get the most benefit, but there's plenty of information for intermediate hackers as well.
Table of Contents
- CPAN
- Perl Module Basics
- Module Design and Implementation
- CPAN Module Distribution
- Submitting Your Module to CPAN
- Module Maintenance
- Great CPAN Modules
- Programming Perl in C
- Writing C Modules with XS
- Writing C Modules with Inline::C
- CGI Application Modules for CPAN
You can purchase Writing Perl Modules for CPAN from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Perl Security Papers (Score:2)
I'll blow the mod point next time I have them, but would appreciate if someone else could get it for now.
Will Apocalypse change Perl enough to hurt CPAN? (Score:2, Interesting)
Re:Will Apocalypse change Perl enough to hurt CPAN (Score:5, Informative)
Re:Will Apocalypse change Perl enough to hurt CPAN (Score:4, Informative)
Perl 6 will not have a "compatibility mode" per se (actually it will in patterns, but that's not what you were refering to); it will have a full-fledged Perl 5 compiler that will compile down to Parrot byte-code just like Perl 6 will (as will Python, Scheme and some other languages).
By its nature, it will have to know more about Perl 6's internals than the other language front-ends, but not by much. You will be able to do something like "perl5 program " and your program will run exactly as you expect, and modules will be auto-recognized (because Perl 6 does not use the "package" keyword).
There is a catch. XS modules (those that directly interface with Perl's internals in order to talk to external C or C++ libraries) may need more help. In most cases, the interface will still be available through some emulation, but some will simply have to be fixed to work with Parrot-based Perl 5.
Re:Will Apocalypse change Perl enough to hurt CPAN (Score:2)
You will be able to do something like "perl5 program "
From what I understand the header controls it so for exampel
#!/usr/bin/perl
works. Further things like
use ABC
will load in perl 5 mode with some other command for perl 6 modules...
Re:Will Apocalypse change Perl enough to hurt CPAN (Score:2)
Re:the Parrot/Perl6 development process (Score:2)
I don't understand the part about indirection from what I've heard the run process looks like:
complex perl -> simple perl -> parrot -> machine
The compile process might be what you describe above but why does that matter?
Re:the Parrot/Perl6 development process (Score:2)
1) Your code won't compile effeciently on all machines
2) You will have code to a lowest common denominator.
The IMCC guys give a great example:
IMCC code:
$I1 = 1
$I2 = 2
$I3 = $I1 + $I2
$I5 = $I3 + 5
Note you only need 2 registers so the Parrot becomes:
Parrot:
set I0, 1
set I1, 2
add I0, I0, I1
add I0, I0, 5
But there is nothing stopping from binding directly against Parrot if you like.
Re:Will Apocalypse change Perl enough to hurt CPAN (Score:2, Insightful)
Re:obsolete book (Score:3, Informative)
I loved this book (Score:5, Informative)
Test! (Score:2, Interesting)
See chromatic's How You (Yes You!) Can Get Involved [perlmonks.org].
CPAN is 80 percent of Perl (Score:5, Informative)
There are just so many amazing libraries in CPAN, I can't get over how most of what I want to do is already there, and at my fingertips. Want process management? WWW client emulation? Scientific computing functions? It's all in there, and managable via the CPAN.pm module.
Come Perl 6, CPAN (or its successor) will be even more valuable. The back-end virtual machine (Parrot) will have modules which give it access to external capabilities, and any Parrot-based language will be able to use them. You'll be able to call Perl's LWP from Python, or a scheme tree-handler from Perl. The details are all being worked on as we speak, but the basic building blocks are mostly in place already.
Re:CPAN is 80 percent of Perl (Score:2)
For now, it's best to let people learn CPAN.pm. CPANPLUS will be fully functional soon....
The hardest part (Score:5, Interesting)
Myself, I have managed to put modules on CPAN, after a few months of wondering why they didn't appear in the main listing. (It turned out I had forgotten to send an updated module list entry; my fault, but still it would have been friendlier for somebody to answer my question about what I did wrong rather than just ignore it.) But uploading newer versions of the same modules has sometimes been troublesome, with the update appearing in my home directory but not the main listing: again, any request for help or guidance on what part of the process I was doing wrong was studiously ignored.
Despite the troublesome upload procedure, CPAN is Perl's biggest asset and other language communities would do well to copy it (as some are). But please don't copy the management system; have some more structured way to submit code where it's clearer what to do at each stage, and there can be warning messages if you do something wrong, rather than just quietly failing to work.
Re:The hardest part (Score:2)
I registered as a CPAN author, got my ID, then registered my namespace and uploaded my module. It all took about 36 hours from sending email to register as an author to my module being on all the CPAN mirrors I checked (ego surfing
And all the documentation says wait 2-3weeks for any action to be taken. I am a very happy CPAN contributor.
narrow WRT language (Score:2)
Is it a hard problem technically, or is it politics?
I wish to know. I see too much reinvention of the wheel in different languages, and consolidation looks more logical if there are no signficant technical barriers that someone can identify.
We are going to make Microsoft look good (.NET) if we cannot figure this out. (Although MS may be making some painful sacrifices WRT variety.)
Re:narrow WRT language (Score:2)
All languages are not created equal.
One language's junk is another language's treasure.
Re:narrow WRT language (Score:2)
What you are suggesting is that people want the libraries to mirror the philosophy of their favorite language.
That is fine, but the drawback is having to reinvent the wheel for every language, new and old.
"I want my wheel my way" is a source of a lot of redundancy in software. I suppose such redundancy may create jobs in some cases, but it just makes the Vulcan area of my brain shudder.
Plus, perhaps having a larger library is more important than having a library customized for each language philosohpy. There might be an obscure format or feature that you want a component for, and if all that effort is spent on deep libraries rather than language-specific duplication, one could prehaps have that.
Re:narrow WRT language (Score:2)
In C, the obvious route is to pass n and the numbers to a varargs function.
In C++, the obvious route is to pass a vector (from the Standard library) to the function.
In Ada, the obvious route is to pass an array to the function.
(Or, with C++ or Ada you could use template/generic functions. Faster, but the disadvantages of C functions.)
In Lisp, the obvious route is to pass a list to the function.
Even ignoring C here, to map a vector to an array to a list takes O(n) time, wiping out any advantages to using the function. You can create a basic library with a vector/list type, and interface it to all three languages, but it will be more clumsy than native types. You end up losing some of the advantages of using each language. (This, of course, is the way that
OTOH, where it's worth it, everyone does use the same library. Look at GTK+; every serious programming language has bindings to it, and it's often the most popular graphic toolkit for that language. Part of what makes that possible, though, is the fact that GTK+ was written in a way that makes that possible; part of what makes it tolerable is that most of those bindings were handwritten, covering the more blatant clashes with GTK and the language. Even then, there's some stuff that can't be fixed; for example, GTKAda has a few problems that no native Ada toolkit would have.
Testing? (Score:2)
-- Yoz
Re:Testing? (Score:2)
There is indeed a section on testing. Of course, there are lots of other [perl.com] resources [perl.com] online [oreillynet.com]. :)
Appropriate reviewers (Score:1)
Which is exactly the reason why someone else should have reviewed it! Books should be reviewed by someone with the appropriate skill set, that's got about the same amount of knowledge that the books intended audience have. If that isn't the case the review is pretty much useless.
Re:Appropriate reviewers (Score:1)
I disagree very strongly. If a book's intended for beginners, an expert really ought to make sure it contains nothing misleading or wrong. In this case, since I'm experienced with building and distributing modules, I think I have a good perspective on the process. Someone who's never done it before won't be able to compare the book to personal knowledge and experience.
Inline rules! (Score:4, Interesting)
perl Makefile.PL
make
make install
sequence, Inline automatically calls the compiler and linker for your C/etc code, and creates the right glue code between your Perl and C/etc code. For a simple example, see the C mailbox parser which comes with <shameless plug>grepmail [sf.net]</shameless plug>.
By the way, recent improvements to the Perl implementation mean that my Perl mailbox parser is now less than 5% slower than the C implementation. Just one data point for those of you who say Perl can't be fast. ;)