CPANizing Behavior and Democratizing Publishing

| 1 Comment

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.

1 Comment

Since I mentioned it last time you brought this up, but didn't hear back, what about CPAN::Site ( http://search.cpan.org/perldoc?CPAN::Site ) didn't solve the problem of having local versions and private packages?

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on June 20, 2011 2:15 PM.

Meaning, Mechanism, and the Tyranny of Dynamic Language Type Checking was the previous entry in this blog.

Rethinking Perl Marketing is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?