The (YAML and Perl Toolchain) Summits

Perl Toolchain Summit Lyon, France, May 11-14 2017

This year I was invited to the Perl Toolchain Summit in Lyon, formerly known as the Perl QA Hackathon. I had organized this event two years ago in Berlin.

Having been "only" an organizer before, this time I could actually code. It was a pleasure to work with over 35 people doing a lot of work for the Perl 5 and 6 infrastructure and related topics.

One of them was Ingy döt Net, who I enjoy working with on Perl and other Open Source projects regularly remotely. Since we both love the commandline, I could learn a lot from Ingy over the last two years.

At the summit we were working on existing and new YAML modules. This is Ingy's report of what we did. Spoiler: We killed and reinvented it.

YAML Summit Berlin, Germany, May 5-8 2017

In this post I would like to talk about the 2017 YAML Summit that took place just one week before the Toolchain Summit.

Ingy döt Net and Felix Krause have been initiating/working on some new YAML projects throughout the last year, and at some point I joined them. Felix wrote a YAML parser in the Nim language. The wish for a new version of the YAML Spec came up. Since Ingy was coming to Europe for the Toolchain Summit, he had the idea to meetup in Berlin, and luckily Felix was able to come from Stuttgart very spontaneously.

pcorelist - a corelist wrapper with shell completion (App::Spec)

Maybe you've read my recent post about App::Spec.

As an example, I've written a wrapper around the corelist tool, which adds shell completion.

Since the options of the original tool weren't ideal for completion, I added subcommands.

Perl Versions, features and modules are completable.

The script is in part a wrapper around corelist, and partly I stole code from it.

I attached a little gif animation which shows the script in action:

What is your most used key on the command line?

Or: Why does writing command line apps still require so much work?

My answer to the first question would probably be: TAB. (Especially since I switched to zsh ~2 years ago.)

But more about that later. This is simply one of the reasons I started this project.

The Problem

When you start a command line tool you probably add Getopt::* as soon as you need options. Maybe Getopt::Long::Descriptive, so you can get a usage output. There's also App::Cmd, MooseX::App, MooseX::App::Cmd, MouseX::App::Cmd, MooX::Cmd and possibly more. Some can't do nested subcommands; they all look and work a bit different. Shell completion just exists for some and would have to be implemented for every single module.

And in the end you have to know about all, since you might work on projects from somebody else.

What they all do is create a commandline app from a specification, but the way you describe it is very different, although the basic concepts have a lot in common.

To get the specification of a tool, you have to run it. So the code for creating completion or usage, for example, has to be written for each of them. And the same for tools written in other languages.

A possible solution or just another reinvention of the wheel?

When I was working on an app which had subcommands and options generated automatically from another source, I had the option of generating a bunch of MooseX::App classes, which would still be lacking things I wanted. Better parameter validation, better completion, ...

So I thought of creating an intermediate format, a specification in text form. This resulted in Just Another Command Line Framwork, which I gave the boring but short name:

App::Spec is the class for representing the specification in perl, App::Spec::Run is the class you should inherit from which runs the actual app.

The QA Hackers have left the building

Finally, the QA Hackathon 2015 in Berlin is over.

It was my first hackathon, and it was a pleasure to organize it. Just to mention a few, I want to thank Andreas for organizing at the venue and staying there as long as people wanted to stay and hack (like midnight), Wendy and Liz for serving all kinds of delicious food, Neil and Olaf for helping me contacting sponsors, Max from for doing the paperwork and letting us use their bank account, BooK and Barbie for giving lots of useful advices for organizing and all the hackers for attending.

Amazon Development Center is sponsoring the Perl QA Hackathon 2015

We would like to announce that Amazon Development Center Germany is sponsoring the Perl QA Hackathon.


The Amazon Development Center Germany is happy to sponsor the Perl QA Hackathon 2015.

In the Kernel and Operating System team we automate testing and qualification of new hardware and the Amazon Linux distribution. …