Jun 5, 2011

My solution to not using PluginBundle:AUTHOR for dzil is git

I am now tired of updating my dist.ini's for my Dist::Zilla projects. For many people this is when they start using a PluginBundle with their authorname. I discussed why you shouldn't do this a year ago. Now that I'm tired of managing my dist.ini's on an individual basis I'm going to show you how I'm going to solve the same problem everyone else is, which is getting tired of updating your dzil configuration for all of your projects. I'm using git to do it. You probably haven't considered this, or am thinking I'm wrong because you believe that git can't merge branches without a common history, which is not true. I did it with Regen2, Funtoo, Portage, and Sunrise, which have way more files than any perl repo, including Perl.


First let's talk about the advantages and disadvantages of doing this with git.

I'll start with the disadvantages. You'll have another repository to manage. Git isn't completely automatic, you'll have to remember to merge your changes. You'll also have to add the repository to your existing repositories. You will have to resolve merge conflicts at least once, and probably occasionally more, though most should be fast-forwards.

The advantages are... now the changes to your dist.ini are getting recorded in your history. You can now have a master dist.ini, but remove items without filters in your individual modules. You can share even more configuration as merged differences allow you to maintain differences in downstream commits. It doesn't automatically update all of your modules. Wait didn't I list that last one in disadvantages? Yep, it's an advantage because what if you update your PluginBundle and that update breaks one of your modules, but you don't know it because you haven't worked on that module in a while. You can use this for more than just dist.ini.

Ok so the first thing you you want to do is create your master dzil repo. This is not a git or dzil tutorial so go do that. I did it by creating a dzil new project and removing the files I couldn't use and making a few tweaks and amending all of those changes to the initial commit. Check out my repo for inspiration. Remember the directory structure has to be the same as a dzil repo structure for any common files.

Now add a remote from your new repo to an existing dzil project. Next you need to merge the branch from the remote into your project. The first time you do this you'll have to resolve conflicts. If they're like mine then they'll be easy and obvious. Once that's done future changes will be fast-forwards unless you change something in your perl module repo, then you might end up with a simple merge conflict. One thing to remember NEVER EVER try to merge from your module repo to your dzil repo, it will cause you extreme pain in the future. cherry-picking that direction is possible but not merging.

After that, all that is left to do is run your dzil tests and fix any breakage in your module. Happy merging.

Regen2 accounts transferred

I killed regen2 about 2 years ago. Today I was contacted by Rafal Kupiec asking about the project. Since it's dead he asked if he could take over the project. I have transfered the github account, and freenode channel #regen2 to him. The google groups are remaining archived. At some point in the future there should be a site at asiotec.org I have no idea what he plans on doing with it.

Jun 1, 2011

Test::Version under maintenance again

About 4 months ago russoz (Alexei Znamensky) sent me a message about quoting the versions generated by Dist::Zilla::Plugin::OurPkgVersion. I was a bit skeptical at first about needing it, and the suggestion seemed to have more to do with style anyways. But after digging a little I found to my horror that OurPkgVersion was generating completely invalid multipart version strings, e.g:

our VERSION = 0.1.0;

Which doesn't work. I was shocked because I was using Test::HasVersion. Well all Test::HasVersion does it checks to see that you have a VERSION defined. My code above will pass a defined test, but you certainly won't get anything if you try to print it.

So I accepted Russoz's patch and fixed up my documentation. Still, I was disturbed that there weren't any Test modules that would have caught this error for me.

So, eventually, I began working on writing a Test module to do this task for me. First it was mostly research and learning which modules and methods I would need. One of the hardest parts was determining how best to extract the VERSION from the module. PPI seemed like an impossible task, probably most due to the fact that I don't understand it. I thought about require-ing modules, but many told me that could lead to a vulnerability in the test. Ultimately decided to use Module::Extract::VERSION which will work for everything except perl 5.12 style versions. Then I had the problem of learning how to write Tests for Test modules, which ultimately doherty (Mike Doherty) contributed some patches to get my first set of tests working.

Once the module was all but finished functionality wise I had to decide on the name, after discussing it on #distzilla it was decided that it might be a good idea to take over an existing module. Test::Version seemed like the most obvious candidate because it has the most obvious namespace for what is trying to be done. So I spent the next few weeks trying to contact particle (Jerry Gay) to get maintainer-ship. Once I did manage to contact him it wasn't an issue to get control of the Module.

So I released a new version of the old Test::Version 0.03 announcing new maintainership, on the off chance anyone was using it in the darkpan, since I'd already searched the CPAN archives for any usage and no current module was. I then released a TRIAL version for testing. The Trial version ended up having several failing tests by cpan tester reports, I thought it was caused by Test::Builder::Tester whitespace sensitivity (and maybe some of it was). rjbs (Ricardo Signes) suggested Test::Tester and I released yet another version with failing tests. This time I analyzed about 5 of the test reports, and come to find out the module seems to run the tests on the perl modules in no particular order. I assume that somewhere there is some speed optimization which results in this behavior. So I had to find a way to write the tests which could handle the fact that I couldn't depend on the order that files were being tested. Ultimately worked that kink out as well in a way that appears to be satisfactory.

So with version 0.07 we now appear to have a working Test::Version. That checks to see if modules have versions, and that they are valid. It's also capable of checking an entire dist. The docs describe use, and if you use Dist::Zilla you can check out Dist::Zilla::Plugin::Test::Version or use Dist::Zilla::Plugin::TestingMania which will be including it.

Going forward I plan to take version 0.07 if it turns out to have no serious bugs, and release version 1.0.0 as it stands. After that I have a few features releases in mind. Including supporting is_strict if you'd like to make sure that your VERSION passes those tests as well. I'd also like to pull in the functionality of Test::GreaterVersion and Test::ConsistentVersion. I'm open to other suggestions as well.

I hope people can make some good use out of this module to avoid silly mistakes like I made.

Happy Testing!

Disqus