A Date with CPAN, Part 10: Cleanliness Is Next to Timeliness

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]


Last time I rearranged our UI to be (hopefully) a bit more intuitive.  This time I want to clean up the remainder of those pesky CPAN Testers failures on our way to the next solid release.

So, the first thing I needed to do was to figure out what all those failures were.  See, as I touched on before, CPAN Testers failures tend to come in groups.  The trickiest part (usually) is identifying the patterns and figuring out what they have in common, which usually tells you what caused the failures.  Once you know what the failures are, it’s often trivial to actually fix them.  Often, but not always.  We have a bit of a mix here, as it turns out.  But first I had to analyze the failures and pick out the patterns.

Except I didn’t have to.  Because the Perl community is awesome, and someone thoughtfully did it for me.  Literally a day or two before I was about to start wading into the fail reports myself, Slaven Rezić (a.k.a. SREZIC on CPAN, a.k.a. eserte on GitHub) opened three GitHub issues wherein he’d already done all the work for me.  So I have to give a big shout out to Slaven: he did the hard part.  And, with the hard work done for me, all I had to do was buckle down and just fix the errors.

A Date with CPAN, Part 9: Composition Defeats Inheritance Yet Again

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]


Last time I talked about fixing the worst of the problems CPAN Testers was thoughtful enough to find for me.  As of this writing, my latest trial version has a 59% pass rate on CPAN Testers, which is a major improvement.  It’s still not good enough, of course, but we’ll look at fixing that next time around.  This time I want to talk about eating your own dogfood.

This is a fairly common expression in the places I’ve worked, but, just in case you’ve never heard it, it means very simply that you should be using the products you develop.  This is a pretty simple concept, if you think about it: if you want your products to make your users happy, you need to be their first user, and you need to demand that they make you happy first.  Especially because you’re the person who can most easily fix whatever problems there are.

So once I had Date::Easy in a usable state—even though it’s still a fairly primitive one—I started trying to use it for things.  Nothing important, of course ... just little quickie things, often from the command line.  Quick, easy command line date fiddling should be one of the things that Date::Easy excels at, after all ... if it’s doing its job properly, anyway.  And I quickly ran into this:

A Date with CPAN, Part 8: Curse You, Daylight Savings Time!

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]


Last time I talked briefly about the raft of failures that CPAN Testers threw up for me to look at.  I mentioned that there were roughly 3 groups of failures, and that one of them was bigger than the other two.  I even gave a hint as to what it was in one of my examples:

cpan-testers --cache --failure "can still use parsedate normally" Date::Easy

That particular string I was trying to isolate is the test name (that is, the third argument to is1) for my unit test that verifies that I’ve undone my monkey-patching of Time::ParseDate.2  Now, I noted when discussing the decision to monkey-patch3 that I could imagine some problems with re-entrant code.  Which might also apply to threading, so my first thought was to see if this failure only happened on threaded Perls, but that wasn’t it.  Then I discovered a configuration argument4 called “pthread” and for a while I thought that was the correlation.  But it wasn’t.  During this time I was engaging in a bit of a back-and-forth on the CPAN Testers mailing list, trying to nail down how I could replicate building a Perl whose config_args would match that of a given smoker.  If you followed the link I gave you to that discussion, you already know what they told me: it’s the timezones, stupid.  (Well, they were much nicer than that.  But I certainly felt stupid.)

A Date with CPAN: And Now, a Word from Our Sponsor

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.]


Today’s blog post is brought to you by CPAN Testers.  CPAN Testers: testing your code on every version of Perl on every operating system in every possible circumstance ... so you don’t have to.

I’ve talked about CPAN Testers before.  If you’ve read that, you probably know how awesome I think they are already.  And, with this foray into creating a date module, they’ve stepped up again.

Now, you will imagine that I made sure all my tests passed on my machine before I dared upload Date::Easy to CPAN.  But that doesn’t mean they’ll pass on everyone else’s machines, so I watched CPAN Testers with some trepidation.  Remember that dates are annoying to get right, and, even though I’m trying to mess with the underlying date code as little as possible, there’s still chances aplenty for things to go tragically wrong.  Which is pretty much exactly what happened.

A Date with CPAN, Part 7: In the Zone

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]


Last time I said that I had three things left to do for Date::Easy before it was ready for CPAN:

  • Add a Time::ParseDate fallback to the ::Datetime class.
  • Figure out how to handle the UTC version of datetimes.
  • (Hopefully) fill out the POD.

This time, I’m reminded of the wise words of the great sage Meatloaf: two outta three ain’t bad.