CPANday 2017

CPANday 2017 is over.

This year I remembered CPANday, after a tweet from @neilbowers pointing to a blog post on CPANday 2017, I even jotted it into my calendar all in due time and promised myself I would contribute something.

As CPANday came closer I still had no plans on what to contribute or what to work on. At the same time my workload at work was immense, having CPANday clashing with a sprint ending and a project deadline.

After a whole day of refactoring a test suite for a service/application, I came home late and was about to give up on the idea of contributing anything at all. I had some candidates, but I was too tired to take on something big or overly complex (or so I thought). I considered what could be low hanging fruit and decided to take a look at my Github issues, to see if anything stood out.

An issue with one of the dependencies I use looked interesting, but still perhaps, not something I could do anything about – I guess my weariness, got the better of me and I just dug in.

The issue was related to my CPAN distribution Date::Holidays and problems building Date::Holidays::CN. Date::Holidays::CN depends on DateTime::Astro, which seemed to be the culprit, I took a look at the issue list for DateTime::Astro and located two RTs:

RT:112240
RT:101846

The first one seemed quite easy and as pretty low hanging fruit, so after consulting the documentation of Module::Install, I got the build script improved and sent my first PR.

Completely fired up by this quick fix I decided to take a look at the remaining issue.

This required some more debugging, but luckily the issue reporter had given a good hint on how to demonstrate the error using Time::Fake.

env PERL5OPT=-MTime::Fake=$(date –date=”2016-08-31 12:00:00″ +%s) prove -b t/006_solar_longitude.t

I had some problems with the date command running on MacOS and I was too tired to get my head around the man page. In order to mimic the example from the issue report.

So I made my own example, calculating the number of days until the end of the month (15 on CPANday).

env PERL5OPT=-MTime::Fake=+15d prove –lib -b t/006_solar_longitude.t

When I was able to reproduce the error, I did some debugging and found out that the construction of a DateTime object failed, due to the fact that the date parameters were illegal (well the error output actually stated this).

After some thinking and useless experimentation it struck me that the construction was sequential, so I reordered the parameters so the day would be before the month, so we would not be altering the default object (based on the current day) so it could be a invalid date. This resulted in my second PR.

All in all a good CPAN day, short, but effective. My PRs got accepted and a new release of DateTime::Astro is now available on CPAN.

I never thought I would be able to contribute anything, so I was quite impressed with myself and my accomplishments. I even picked up a few new tricks, like Time::Fake.

I still have no idea why DateTime::Astro is needed, but it does not really matter, since the issues were a SMOP.

Now I am just looking forward to CPANday 2018.

jonasbn, Copenhagen

CPANday 2017

Test::Timer Release 2.00

Received some feedback on release 1.00 of Test::Timer, this has resulted in further improvements and release 2.00.

The diagnostics of failing tests using Test::Timer, now also presents the actual execution time observed.

Next goal of the next feature release, is to handle higher resolution than seconds. In the mean time a release with improved documentation is planned to go out.

Until next Timer – release, take care

jonasbn

Test::Timer Release 2.00

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,

jonasbn

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,

jonasbn

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

jonasbn

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

CPAN Pull Request Challenge 2017

I just received a mail from Neil Bowers asking if I would consider having my CPAN distributions be a part of the 2017 CPAN Pull Request Challenge.

My undelayed mental response: Well of course…

I participated in the 2016 Hacktoberfest, I did not contribute much, but I participated and I would have loved to contribute more. These sort of “events” are good, IMHO they bring out the best in open source and they demonstrate the essence of the open source community.

In addition they help tie a community together, so when you are like me; a maintainer of CPAN distributions with very little time, every patch and every PR is most welcome.

A CPAN Pull Request Challenge gives you exactly that.

The CPAN Pull Request Challenge 2017 is soon to kick off, which mean YOU have a chance to benefit from this incredible initiative.

If you have received a mail from Neil respond and be take into consideration for possible PR coming your way or you can tag your issues on Github with the label:

cpan-prc-2017

In order to add the label you have to do the following (This can possibly also be accomplished via the Github API, but that is beyond this blog post):

1. Go to you Github repository issues page
2. Click “Labels”
3. Click “New label”
4. Add the label “cpan-prc-2017”

This mean that the label will be present for both issues and PRs.

Please note that labelling issues will not make them go away automagically, but it will be easier for participants to find issues suitable for the challenge, and also lets participants know that you’re open to a PR for that issue. Since they can be easily identified using a primitive search:

https://github.com/search?q=label%3Acpan-prc-2017&ref=searchresults&utf8=%E2%9C%93

Ask not what you can do for the CPAN Pull Request Challenge 2017, but what CPAN-PRC-2017 can do for you.

This blog post has primarily been on getting help with your distributions and issues from the challenge – there is of course also the option of participating as a contributor of PRs.

Please read more about CPAN Pull Request Challenge at: http://cpan-prc.org/

Have fun – looking forward to your PRs,

jonasbn

CPAN Pull Request Challenge 2017