Moving CPAN RT tickets to Github, now improved

When I wrote about migrating RT tickets to Github a couple years ago, it was a quick-and-dirty job. This week, I finally cleaned it up and added some features I'd been missing:

  • Automatically closing the migrated RT ticket with a hyperlink to the new Github ticket
  • Migrating "stalled" RT tickets, as well as "new" and "open" tickets
  • Including all comments, not just the opening one, along with creator email and creation time stamp
  • Including hyperlinks to any file attachments
  • Including a list of all "requestors" email addresses (people following the ticket)
  • Improving distribution name detection for people who don't use Dist::Zilla
  • Adding a "dry-run" mode
  • Adding a "single-ticket" mode

Here's a draft of what a newly migrated ticket might look like (from a test run, not an actual migration, but it shows an attachment):

Migrated ticket example

Or, here's an actual ticket migrated over for IO::CaptureOutput: Bad joining of STDERR + STDOUT in windows [ #55164].

I've created a github repository for this at zzz-rt-to-github to make it easy for people to grab the script or contribute back. The README file there has instructions.


Posted in cpan, perl programming | Tagged , , , , , | Comments closed

Setting up a Perl Development Environment with plenv

This is a slightly modified copy of something I posted internally at work about setting up a development environment using plenv, which keeps your working Perl isolated from your system Perl. Many expert Perl developers already have some variation of this, but I'm posting it as a public service for people who've wanted this but never got around to it.

(I used to use perlbrew, but switched to plenv and haven't looked back).

Step 0: Install compilation tools

Make sure you have a command-line compilation environment ready:

  • Mac: install Xcode or Xcode command line tools
  • Debian-based: sudo apt-get install build-essential
  • Fedora-based: sudo yum install make gcc

Step 1: Install plenv

(This is excerpted almost verbatim from the documentation for plenv)

This will get you going with the latest version of plenv:

1.1 Check out plenv into ~/.plenv.

$ git clone git:// ~/.plenv

1.2 Add ~/.plenv/bin to your $PATH for access to the plenv command-line utility.

$ echo 'export PATH="$HOME/.plenv/bin:$PATH"' >> ~/.bash_profile

Ubuntu note: Modify your ~/.profile instead of ~/.bash_profile.
Zsh note: Modify your ~/.zshrc file instead of ~/.bash_profile.

1.3 Add plenv init to your shell to enable shims and autocompletion.

$ echo 'eval "$(plenv init -)"' >> ~/.bash_profile

Same as in previous step, use ~/.profile on Ubuntu, ~/.zshrc for Zsh.

1.4 Restart your shell as a login shell so the path changes take effect. You can now begin using plenv.

$ exec $SHELL -l

1.5 Install perl-build, which provides a "plenv install" command that simplifies the process of installing new Perl versions.

$ git clone git:// ~/.plenv/plugins/perl-build/

1.6 Build a version of Perl. The following line builds in parallel, enables threads and disables man pages (to save space).

$ plenv install -j 9 -D usethreads -D man1dir=none -D man3dir=none 5.20.1 

1.7 Rebuild the shim executables. You should do this any time you install a new Perl executable (for example, when installing a new Perl version, or when installing a cpanm that provides a command).

$ plenv rehash

You can get help using plenv with "plenv help".

Step 2: Enable the Perl you just built

You can set your Perl in two ways:

  • local Perl – within a directory (and subdirectories); keeps things isolated but might surprise you if you're working out of multiple directories
  • global Perl – always the default Perl in your PATH; consistent everywhere, but could break code that assumes a different version of Perl or different installed dependencies

To set the Perl locally, change to the directory you want and run this command (to set the version to 5.20.1, as built, above):

$ plenv local 5.20.1

To set the Perl globally, run this command:

$ plenv global 5.20.1

Verify you have the Perl you intended:

$ perl -v

Step 3: Install the "cpanm" CPAN client

The "cpanm" command line tool is a popular, zero-config CPAN client. Plenv can install it for you into the currently running Perl:

$ plenv install-cpanm

Step 4: Install CPAN modules you need

For example, to install Moose, use this command:

$ cpanm Moose

If all dependencies build OK, Moose will be installed. If errors occur, a log file location will be shown for further analysis.

You can install multiple CPAN modules by listing them on the command line:

$ cpanm DBI DBD::SQLite JSON::MaybeXS

You can get help with "cpanm --help".

Posted in perl programming, toolchain | Tagged , , , | Comments closed

Flaming people versus flaming code

I think the Perl community in general (perhaps like many open source communities) suffers from two interrelated flaws:

(1) We think flaming someone's code is an acceptable or useful form of technical critique
(2) We react to flames against our code as personal attacks

When both occur, we have problems.

Statements like "this code is stupid" or "this code is insane" aren't constructive because they don't contain any useful information about what was seen as a problem and because most people reasonably take pride in their work and don't like hearing it disparaged.

Better: "This code is insane because it changes the public API" or "This code is stupid because it adds too many dependencies".

Even better: "I don't like this code because it changes the public API" or "I wouldn't use this code because it adds too many dependencies"

It's possible this generalizes into the "you/I" forms of argument.

E.g. "You're insane" vs "I'm angry" vs "When you add extra dependencies to a module I depend on, I get angry because I try to keep a minimum dependency tree and it means I have to do work to find an alternative to something I used to be able to rely on."

The next time someone's code bothers you, step back from your initial inclination to flame the code, and find a more constructive way to convey the specifics of what bothers you.

Posted in perl programming | Tagged , , | Comments closed

Back on the iron blogging horse

When the Perl Iron Man challenge was going, I blogged regularly. At a certain point, I stepped it down, and then, since last May, stopped.

It's time to get back on that horse.

I'm going to be aiming to meet the original Iron Man goals: 4 posts every 32 days, with no more than 10 days between posts.

And for January, I'm going to play catch up with a couple quick articles to follow.

If you've fallen off in your blogging, I invite you to join me.

Posted in Uncategorized | Comments closed

The next Test::More might break fragile test modules

I recently submitted a patch for Test::More that improves subtest readability, but might break fragile test modules. As part of the pull-request discussion, I promised to blog about the change to warn people, so here it is.

When Test::More added subtests (usable as of 0.96), the name of the subtest only appeared at the end of the output, like this:

ok 1 - regular test
    ok 1 - first test
    ok 2 - second test
    ok 3 - third test
ok 2 - my first subtest

That's a bit confusing, because it looks like the indented tests belong to the "ok - regular test", not the "ok 2 - my first subtest".

In Test::More 0.99, a leading comment was added to clarify:

ok 1 - regular test
    # Subtest: my first subtest
    ok 1 - first test
    ok 2 - second test
    ok 3 - third test
ok 2 - my first subtest

That's better, but still hard to pick out in a large amount of test output.

My pull request outdents the comment like this:

ok 1 - regular test
# Subtest: my first subtest
    ok 1 - first test
    ok 2 - second test
    ok 3 - third test
ok 2 - my first subtest

I think this is much easier to read because it brackets the subtest information at the same indentation level. The subtest details are clearly between the opening comment and the matching "ok".

This is likely to be merged and released soon.

Since comments don't have any meaning in TAP, it shouldn't change how tests are parsed. But CPAN test modules might — in their own tests — be looking for specific output and start breaking. Such tests are inherently fragile, and should be changed to use a TAP parser instead of parsing literal text, but in the meantime, if your favorite test class fails its tests, this Test::More change might be the reason.

Posted in perl programming | Tagged , , , , | Comments closed

© 2009-2015 David Golden All Rights Reserved