Hi! Please consider following me on twitter: @hanekomu.

2010年07月16日

Modern Perl administration tools

I'm probably preaching to the choir (the phrase we use in German is more like "bringing owls to Athens") and I'm certainly not saying anything new here, but I would like to talk about two modern tools that make working with Perl versions and CPAN distributions very easy: perlbrew and cpanm.

perlbrew

perlbrew (see App::perlbrew) automates building and installing various perl versions in the user's home directory.

curl -LO http://xrl.us/perlbrew
chmod +x perlbrew
./perlbrew install

With this, perlbrew installs itself to ~/perl5/perlbrew. Now you can do (and I'm quoting from the App::perlbrew documentation):

# Initialize
perlbrew init

# Install some Perls
perlbrew install perl-5.12.1
perlbrew install perl-5.8.1
perlbrew install perl-5.11.5

# See what were installed
perlbrew installed

# Switch perl in the $PATH
perlbrew switch perl-5.12.1
perl -v

# Switch to another version
perlbrew switch perl-5.8.1
perl -v

# Switch to a certain perl executable not managed by perlbrew.
perlbrew switch /usr/bin/perl

# Or turn it off completely. Useful when you messed up too deep.
perlbrew off

# Use 'switch' command to turn it back on.
perlbrew switch perl-5.12.1

cpanm

cpanm is a script to get, unpack, build and install modules from CPAN. It does so in pretty much the simplest way possible, without dependencies or configuration.

To install it onto a freshly brewed perl, use this command:

curl -L http://cpanmin.us/ | perl - App::cpanminus

Then you can do (and again, I'm quoting from the App::cpanminus documentation):

cpanm Test::More                                 # install Test::More
cpanm MIYAGAWA/Plack-0.99_05.tar.gz              # full distribution path
cpanm http://example.org/LDS/CGI.pm-3.20.tar.gz  # install from URL
cpanm ~/dists/MyCompany-Enterprise-1.00.tar.gz   # install from a local file
cpanm --interactive Task::Kensho                 # Configure interactively
cpanm .                                          # install from local directory
cpanm --installdeps .                            # install all deps for the current dir
cpanm -L extlib Plack                            # install Plack and its deps to extlib
cpanm --mirror http://cpan.cpantesters.org/ DBI  # use the fast-syncing mirror

The cpanm --installdeps . command will work if you have a Makefile.PL or a Build.PL in the current directory, but if you use Dist::Zilla you're likely to use a plugin that generates the Makefile.PL and the dependencies for you. In that case you can use this:

dzil listdeps | cpanm --skip-installed

Another tool that works well with cpanm is cpan-outdated (see App::cpanoutdated). It will simply list all the outdated modules' distribution names in a format that can be directly passed to cpanm:

cpan-outdated | cpanm

There are some modules that I need for every Perl installation that I'm working with, and I've bundled them into Task::BeLike::hanekomu. So after brewing a new version of perl, I'll do:

cpanm Task::BeLike::hanekomu

and get all the absolute necessities like App::Ack, App::Rgit, Devel::NYTProf and so on.

Write a comment | Bookmark and Share

posted at: 15:56 | path: /cpan_gems | permalink | 2 comments | 0 trackbacks

2010年03月17日

Use parent.pm instead of base.pm

For years, the common way for your class to inherit from one or more superclasses was the base module. For example:

package Game;
sub new { bless {}, shift }

package Baduk;
use base 'Game';

This works, but some people, me included, aren't quite happy with that. Basically, the above could also be expressed as:

package Game;
sub new { bless {}, shift }

package Baduk;
our @ISA = qw(Game);

If the two packages were in different files, the Baduk package would have to load the file where the Game package lives in as well. But that's about it.

However, base.pm goes further than that. It supports deprecated pseudohases, tries to be clever with $VERSION and generally just does too much. A lot of cruft has accumulated over the years. So a new module, parent, was forked from base.pm and cleaned up.

Using parent.pm is pretty much the same as base.pm:

package Game;
sub new { bless {}, shift }

package Baduk;
use parent 'Game';

This will try to load Game.pm as well. If the Game package is in a different file that is already loaded, you can tell parent.pm not to try to load the file:

package Game;
sub new { bless {}, shift }

package Baduk;
use parent -norequire, 'Game';

Compare the source of the two modules and you will find that parent.pm is a lot cleaner and easier to understand.

Write a comment | Bookmark and Share

posted at: 23:26 | path: /cpan_gems | permalink | 3 comments | 0 trackbacks

2009年08月02日

At the edge of CPAN

CPAN is vast. Many things happen in the Perl 5 world right now. And even though I think I have quite a good overview of the Perl module landscape, there are always new distributions being developed by fresh new Perl hackers.

Here are some interesting distributions for you to look at, if you don't know them already.

Write a comment | Bookmark and Share

posted at: 11:40 | path: /cpan_gems | permalink | 0 comments | 0 trackbacks

2009年02月13日

Bringing the C API into Perl space

Around the turn of the century, when a limit was reached on how far you can mess with pure Perl, inspired Perl (and C) hackers have turned to the Perl C API.

In the last few years many modules have been released that bring the C API into Perl space: Devel::Declare, Devel::Caller, Scope::Upper, Variable::Magic, B::OPCheck and many more. It's a whole new level of fun, or a new level of chaos, depending on how you look at it.

I believe that this is the best effect that the whole Perl 6 discussion and development had so far.

Write a comment | Bookmark and Share

posted at: 13:37 | path: /cpan_gems | permalink | 0 comments | 0 trackbacks

2008年09月12日

CPAN Gems: Proc::InvokeEditor

This is the first in a series of posts where I will show you CPAN modules I've stumbled across. If I find an interesting and well-documented module, I'll post the relevant part of the manpage.

Today, please take a look at Proc::InvokeEditor by Michael Stevens.

Proc::InvokeEditor - Perl extension for starting a text editor

use Proc::InvokeEditor;
my $edited_text = Proc::InvokeEditor->edit($unedited_text);

This module provides the ability to supply some text to an external text editor, have it edited by the user, and retrieve the results.

The File::Temp module is used to provide secure, safe temporary files, and File::Temp is set to its highest available level of security. This may cause problems on some systems where no secure temporary directory is available.

When the editor is started, no subshell is used. Your path will be scanned to find the binary to use for each editor if the string given does not exist as a file, and if a named editor contains whitespace, e.g. if you try to use the editor "xemacs -nw", then the string will be split on whitespace and anything after the editor name will be passed as arguments to your editor. A shell is not used but this should cover most simple cases.

Write a comment | Bookmark and Share

posted at: 09:11 | path: /cpan_gems | permalink | 0 comments | 0 trackbacks