CPANizing Behavior and Democratizing Publishing

If you look at the darkpan-inject program in my CPAN::Dark experiment, you'll see something I found curious:

use CPAN::Dark;
CPAN::Dark->new->inject_files( @ARGV );

That's all. If you already have configured your CPAN::Mini installation, my little wrapper around CPAN::Mini::Inject does everything else for you, including setting up a sparse CPAN mirror. It'd configure CPAN clients for you too, if there were an easy way to do so.

Why? Why not! I'm lazy. I'm happy providing sane defaults that will work on all machines to which I deploy, if that means I can avoid tedious, time-consuming, fiddly steps I'm likely to get wrong in various interesting ways.

More than that, I'd rather write a module than a program, because I arrange my programs like modules anyway, and the infrastructure for testing and documenting modules is much better than the infrastructure for testing and documenting programs.

I realized this as I pondered the build system we use for Modern Perl and several other books. (More and more people ask if they can use the build system for their own projects, and I'm thrilled to tell them yes.) I used to think I'd eventually extract the build system into its own Github project which people could clone if they wanted to write a new book, but eventually my good sense as a software developer finally kicked in.

The Onyx Neon book tools don't belong as, primarily, a Github project. They belong on the CPAN. Creating a new book shouldn't require forking a project and copying some files around—especially as those files are programs longer than a dozen lines. Creating a new book could be as easy as creating a new CPAN distribution with Dist::Zilla or a new web project with Dancer (or Catalyst or Mojolicious or whatever).

Certainly you'll have to fill in a configuration file with some specific information, but most of the infrastructure required to build a PDF or an ePub file or nicely-formatted HTML is already on the CPAN. Why not go all the way?

Making a program into a module and excising all but two lines of the program won't solve every problem, but the module is still available for people to use to write their own programs. It's easy—and the common things, if the common configurations are correct—are simple. (Creating a documentation-only tutorial is also easy, and it puts the documentation for layouts and workflow and even syntax and usage recommendations in the hands of potential authors and editors.)

Come to the Book Author BOF at YAPC::NA 2011 or catch me in the hallway track or talk to me at Open Source Bridge for more details.