Of course you can use CPAN. And here's why.
Tue May 26 20:20:00 2009
But I can't use CPAN!
Short answer: BOLLOCKS
Longer answer: Maybe you can't use 'cpan', as root, on the target system. But you can almost certainly use CPAN modules in your code.
Long answer: To follow after an explanation of why I'm writing this.
So why are you writing this?
Well, nameless imaginary questioner, I'm writing this because I hang out on freenode #perl a lot (in fact, I'm one of the ops on there, though I'm not sure I'm exactly the most active these days). I'm writing this because every single day, somebody says "hey I want to do X" and we say "well, to do X, you use module Y" and then they say "but it isn't in core, I can't use CPAN!".
What follows is usually a depressingly repeatable discussion of us trying to figure out why the hell they think they can't use CPAN and correcting that mistaken assumption. Except half the time they get upset half way through so we don't actually manage to help them. Which is exceedingly irritating.
And what pushed me over the edge today was hearing "Basically it seems if you cant use CPAN, you may as well not ask in here". Which is insane - in the few cases where somebody genuinely can't use the modules we'd suggest, we're happy to find them another way of doing the job (although often it turns out the answer is "open the source of the module you should have used and steal some bits", which is kind of meh, but never mind ...).
So, it's time to go over some common scenarios and why they don't stop you using CPAN and why you should be learning how to use your tools to be able to leverage CPAN instead. Which is the long answer.
The long answer (finally)
So, let's go over the different possible situations:
I can't use CPAN because I don't have root.
That's ok, if you have a shell and a compiler then you can use local::lib to bootstrap and then use a ~/perl5 installation target that all your scripts will be able to use just fine - I've deployed large and complex apps onto Dreamhost this way, and use it all the time for shared development servers where I don't want to install modules globally.
I can't use CPAN because my users won't want to install things.
Well, if you're distributing vendor packages, you can just provide appropriate dependencies to those. Assuming you're just handling your users a tarball, then Module::Install provides a solution - if you put your script into script/ and then do
install_script(glob 'script/*'); auto_install;
in your Makefile.PL, then not only will 'make install' put your script somewhere useful for you but 'make installdeps' will invoke cpan (or if present, cpanplus) to install all missing dependencies for you.
I can't use CPAN because I'm only distributing a .pl file
Well ... in my opinion, you probably actually wanted to distribute a distribution with a Makefile.PL (at which point see previous case), but rather than argue that point I'll mention the solution to this one - the PAR suite. Using PAR::Packer you can pack all of your dependencies, and your application, into a single script file (which if you have no C-based modules in there will be cross platform), or if you know your target architecture you can go as far as simply building an executable that includes everything right up to the perl interpreter.
I can't use CPAN because my code needs to run on a cross compiled microperl on the Nintendo DS.
You, sir, have a valid excuse. Please feel free to ask us how to do this using only core modules :)
You probably can use CPAN, or at least most of it, and you probably wanted to, really, because it's easier to learn the tools once than to reinvent the parts you need on every project.
UNIX is my IDE. perl5 is my VM. CPAN is my language.