Test::Timer Release 1.00

Yesterday while sitting at the computer working on a release Workflow I received a Github issue.

Test::Timer is a Perl test module that can assist in specifying timing thresholds for code execution. You can then specify that your test suite should break if the code takes too little or too much time.

The concept requested was simple, in the diagnostic messages emitted from the module, the thresholds specified should be mentioned. The implementation did not take long to implement.

However since the diagnostic messages was changed and somebody might be relying on these I decided to make it a major release to indicate this somewhat breaking change.

Thanks to Nigel Horne for the issue report I hope the implementation meets your needs and expectations.

Test::Timer 1.00 has been uploaded to CPAN, feedback most welcome.

Have a nice weekend,


Test::Timer Release 1.00

Workflow Release 1.43

First release of Workflow in a long time, but luckily I received a pull request from Oliver Welter

Oliver Welter has earlier offered patches implementing custom workflows (1.35 and 1.37) and factory subclassing (1.35) and now improvements in logging for condition validation with the latest release 1.43 – thanks Oliver, you make me look lazy 🙂

During the testing of the release I ran into an issue with the Dist::Zilla plugin: Dist::Zilla::Plugins::CJM. Related to failing tests due to deprecation. David Golden has offered a pull request, but the author Christopher J. Madsen seems unresponsive and his activity level on Github has flatlined :-/

Changed configuration to an alternative by Dave Rolsky and everything seems to be running as expected.

Release should be available on CPAN shortly – have a nice weekend,


Workflow Release 1.43

Date::Holidays 1.04 and 1.05 Released – introducing Belarus

I am happy to announce a new release of Date::Holidays. The release is 1.04 and is based on work by Vladimir Varlamov, namely an adapter for Date::Holidays::BY, a module for handling holidays in Belarus.

Thanks to Vladimir for his contributions.

Unfortunately I got carton’s local/ directory included in the distribution tar-ball, which Alexandr Ciornii (CHORNY) was quick to tell me so 1.05, got shipped shortly after.

Thanks to Alexandr for bug report.

Holiday season is coming up, so check out Date::Holidays


Date::Holidays 1.04 and 1.05 Released – introducing Belarus

Aloha Module::Info::File

“Aloha: Means hello and Ehh.. also goodbye” – Bighead

I have just processed some old PRs for Module::Info::File. A Perl distribution I created a long time ago. The module was implemented as a subclass of Module::Info, which I thought lacked some use-cases like basic file handling.

Actually the whole module concept came from a script named version.pl, which extracted basic meta data from Perl packages and Perl module files – this led me to Module::Info and to a solution of subclassing into Module::Info::File.

Anyway I got the PRs processed and got the whole thing working nicely. I had a look at the internals and was not satisfied, parsing version numbers in Perl components have always been interesting.

Based on a old note I had a look at Test::Version a module to test your version strings assuming it did something clever I had not thought of. It appeared that Test::Version was just based on Module::Metadata.

Module::Metadata looks quite impressive so I decided to pull out all the internals of Module::Info::File and implement new logic founded in Module::Metadata – *clickity* *click* – version 1.00 ready and after some testing and adjusting uploaded to PAUSE/CPAN.

The Module::Info::File distribution contains a test to check whether the superclass Module::Info would implement the same functionality, causing Module::Info::File to be obsolete – this just never happened.

Just out of curiosity I read up on Module::Info, which had had several releases, a new maintainer and new functionality, which should have caused the mentioned tests to fail.

I had a look at the documentation and fell over the following:

“Module loaded using new_from_file() won’t have this information in which case you can set it yourself.”

So I thought why not look into whether my code can be ported to the superclass, since I actually do that, I did it prior to 1.00 and I do with 1.00…

Looking around for a Github repository link I ended up in the issues/bug tool RT. Here RT:115147 stood out.

“I wonder if it is time to deprecate Module::Info, or at least point to Module::Metadata as the in-core and preferred mechanism for gathering module information? It looks like Module::Info’s mechanism for parsing $VERSIONs out of files is quite incomplete and outdated.”

I had just changed Module::Info::File to use Module::Metadata and going over the newer releases of Module::Info I located module_info a magnificent tool for replacing my own version.pl – except for the fact that it outputs the filename instead of the package name when providing it with a file as argument.

So now I am unsure of what way to go:

  • Should I deprecate Module::Info::File and just play along with Module::Info and it’s module_info
  • Should I talk to the current maintainer of Module::Info about using Module::Metadata internally so the file handling would improve, since I just observed that worked for Module::Info::File 1.00 and then deprecate Module::Info::File
  • Or should I just forget the whole  Module::Info / Module::Metadata thing and focus or maintaining Module::Info::File

Anyway it is all in the life-cycle of Perl distributions – distributions come and go…

Aloha Module::Info::File

Date-Pregnancy 0.06 released

When I woke up this morning, I had received an email from somebody who are repackaging a Perl distribution of mine Date-Pregnancy for Debian.

I have been extremely busy the last 4 months with work, so I have not contributed anything to open source at all and I have not been doing much work on this sphere at all.

But now it is my winter holiday and I thought, why not process this patch as rapidly as possible to acknowledge the person who take the time to repackage my distribution and also took the time to correct spelling errors in my documentation.

So today I published Date-Pregnancy 0.06 to CPAN.


Date-Pregnancy 0.06 released


I have just revived a lot of my CPAN distributions after they where stranded in migration. One these distributions is Date::Holidays a wrapper/adapter to modules in the Date::Holidays namespace and related. Since development started up again I have made several releases and I am on a quest to get all of the RTs/issues out of the way.

Some release history:

0.19 2014.08.27 bug fix release, update not required (see below)

– This release addressed reports on failing tests for perl 5.21
The use in this distribution of UNIVERSAL is now deprecated,
see: Github issue [#3] and [RT:98337]

0.18 2014.08.24 feature release, update not required

– Added adapter class for Date::Holidays::BR [RT:63437]

0.17 2014.08.22 maintenance release, update not required

– Migrated from Module::Build to Dist::Zilla

– Fixed issue in some test, which would break if Date::Holidays::DK
was not installed

0.16 2014.08.18 maintenance release, update not required

– Fixed POD error

– Aligned all version numbers

– Added t/kwalitee.t Test::Kwalitee test

– Added t/changes.t Test::CPAN::Changes test

What struck me when I was shifting back and forth between perl versions on my laptop and had to install some of the Date::Holidays modules over and over again, was:

  1. I have to refamiliarize me with my own code
  2. I have to get an overview of what new distributions have been added to the namespace and acquire my attention, I feel like I have been on a looooong holiday
  3. I seriously need to get some work done and get some releases out

Enter Task::Date::Holidays! – using this distribution it will be easy for me to get all of the interesting distributions installed when I have completed point 2, then I can focus on point 3 and point one will solve itself.

Task::Date::Holidays 0.01, contain the following list of distributions:

– Date::Holidays::AT
– Date::Holidays::NO
– Date::Holidays::DK
– Date::Holidays::DE
– Date::Holidays::GB
– Date::Holidays::PT
– Date::Holidays::ES
– Date::Holidays::PL
– Date::Holidays::CZ
– Date::Holidays::KR
– Date::Holidays::SK
– Date::Holidays::FR
– Date::Holidays::BR
– Date::Holidays::CA_ES
– Date::Holidays::USFederal
– Date::Holidays::CA
– Date::Holidays::CN
– Date::Holidays::NZ
– Date::Holidays::AU

Many of these are completely new to me, so this will be very interesting – so expect plenty of releases of Date::Holidays as I chew my way through the list…

jonasbn, Copenhagen


Continous Integration with Travis CI and Github for Distzillians

This post started out at a comment on a blog post, but it was simply not possible for me to comment on the relevant post, so I have edited my comment into a blog post even though most of the contents are not mine :-/

So all the Kudos, credits, beers and stuff for the contents of this post should really go to: Alex Balhatchet, read his post:


Okay – I have migrated all of my CPAN distributions to Github and all new projects start up here. Over the years I have used Jenkins for continuous integration, so I was very happy when I found out that Github offered continues integration using Travis.

I had everything going with Module::Build, which have been my preferred build system and one I have been using for a long time, with Travis CI on Github, but recently I have started porting all my distributions from Module::Build to Dist::Zilla, which meant that I had to revisit my whole toolchain.

Finding Alex’s article was just what I was looking for.

The after reading Dave Cross blog post and presentation I got coverage with coveralls integrated (see my blog post on those spiffy badges)

In order to get coverage integrated with Alex’s example, I have made the following changes to his suggested setup.

install is extended with:

– cpanm –quiet –notest Devel::Cover::Report::Coveralls
– cpanm –quiet –notest Dist::Zilla::App::Command::cover

and this additional after_success section has to be added:

– dzil cover -outputdir cover_db -report coveralls

I did run into some issues with Alex version, so I have to explicitly install Test::Kwalitee since the version on the Travis CI platform is apparently too old, so also under install I do:

– cpanm –quiet –notest Test::Kwalitee

The Test::Kwalitee issue should go away Karen Etheridge patched her Dist::Zilla plugin

An in addition I also had to install the dependencies of the plugins explicitly under install:

– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied

This was due to an issue with Pod::Coverage tests, where Pod::Coverage::TrustPod.pm is missing.

You can have a look at one of my setups from my code Github:

language: perl
– “5.18”
– “5.16”
– “5.14”
– “5.12”
– “5.10”


# Prevent “Please tell me who you are” errors for certain DZIL configs

– git config –global user.name “TravisCI”


# Deal with all of the DZIL dependencies, quickly and quietly

– cpanm –quiet –notest –skip-satisfied Dist::Zilla

# Hack to getting the latest Test::Kwalitee

– cpanm –quiet –notest Test::Kwalitee

# Getting coveralls report

– cpanm –quiet –notest Devel::Cover::Report::Coveralls

# Getting cover command for Dist::Zilla

– cpanm –quiet –notest Dist::Zilla::App::Command::cover

# Getting all the plugins used by Dist::Zilla in this particular setup

– dzil authordeps | grep -vP ‘[^\w:]’ | xargs -n 5 -P 10 cpanm –quiet –notest –skip-satisfied

# Getting all the dependencies requested by author

– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied


# Getting all the dependencies requested by distribution

– dzil listdeps | grep -vP ‘[^\w:]’ | cpanm –quiet –notest –skip-satisfied


– dzil smoke –release –author


– dzil cover -outputdir cover_db -report coveralls

Thanks to Alex Balhatchet for the post – and thanks to Dave for his awesome post and Karen for most impressive responsiveness, when reporting an issue.

Continued good day,

jonasbn, Copenhagen

Continous Integration with Travis CI and Github for Distzillians