Author Archives: Oliver Gorwits

Following the lead of Mike Doherty (DOHERTY) I’ve moved my own Dist::Zilla Author PluginBundle into a new namespace: Dist::Zilla::PluginBundle::Author::OLIVER Having Author PluginBundles is a great system for saving me time and allowing others to build my modules with ease. However I had to agree to Mike’s point that polluting the Dist::Zilla::PluginBundle:: namespace wasn’t so cool. It also makes things more clear in the dist.ini file: [@Author::OLIVER] If you have an Author PluginBundle, please consider moving it into this new namespace. You can of course keep the old one around, in parallel, until code using it has moved off to the backpan…. Continue reading →

The CPAN META specification includes support for "resource" links to homepage, bug tracker, mail list, source code repository, and so on. These will appear on search.cpan.org if you ship a META.json with your distribution. Dist::Zilla’s MetaResources plugin allows you to set these links in the distribution config, but I wanted something a little more automagical. This can be done because I’ve set up my GitHub repositories with consistent naming and layout. So my new plugin, Dist::Zilla::Plugin::MetaResourcesFromGit, is a drop-in replacement for the standard MetaResources plugin. It automatically generates four resource links based on the name of the distribution and the remote git repository settings. Simply use the plugin in your dist.ini file: [MetaResourcesFromGit] The default links are equivalent to: homepage = https://github.com/<account>/<repo>/wiki bugtracker.web = https://rt.cpan.org/Public/Dist/Display.html?Name=<dist-name> repository.url = git://github.com/<account>/<repo>.git repository.web = https://github.com/<account>/<repo> repository.type = git Any other resources provided to this Plugin are passed through to the MetaResources Plugin as-is. If you wish to override one of the above, some formatting codes are provided (described in the documentation) to assist. If you wish to suppress the appearance of one of the above resources, set an empty value. If you want to know more about my Dist::Zilla and GitHub workflow, I discussed it in an earlier post on this blog. I wrote this plugin to assist me, and it’s also shown how great the Moose-based Dist::Zilla architecture is for extending features. The Plugin is GitHub centric at the moment, but I’d be happy to accept a patch to work with other cloud-based Git services (Gitorious, SourceForge, etc)…. Continue reading →

There has been a bit of discussion recently on the #distzilla IRC channel about how people are integrating their CPAN distribution development with Git, and in particular some of the Dist::Zilla Git plugin(s). I thought it might contribute to a useful discussion if I show how I have things set up. Like many, I want to host my code on GitHub and then periodically publish to CPAN. Dist::Zilla helps in both these by providing plugins to automatically push releases to GitHub, and then also upload to CPAN. What bothers some is the stage at which these things happen, and also how the branches and tags are represented on GitHub. In particular, folks might want: a "clean" git branch which tracks CPAN releases another branch which is the "trunk" of development a user browsing the GitHub website to see the CPAN branch (with the README, etc) sane commit messages and tags What I have configured is for the master branch on GitHub to be the one tracking CPAN releases. This makes it straightforward for most people to fork the distribution and tinker around without getting into trouble (i.e. they can build the dist). My trunk of development takes place in a branch called devel, and that is from where I kick off Dist::Zilla builds and releases: Tags are applied to the master branch automatically, with the version number which was uploaded to CPAN. So a user can again browse to GitHub, and when selecting a (version) tag they will see the CPAN dist at that version. The commit message for the the master branch is also automatic, and contains the text of the latest section in the Changes file. Commit messages along my devel branch are of couse the everyday notes I make as I code. But following a Dist::Zilla driven release, one commit is done automatically on the devel branch to store the new header in the Changes file, and it gets the comment "Bumped changelog following rel. v%v". Okay, this is all a bit abstract, so if you follow this link you can see the network graph for one of my modules. It clearly shows the two branches, how they are merged, and all commit messages. I think this setup is really neat and tidy, and very intuitive for the visiting user who might not be familiar with Dist::Zilla. It’s also almost completely automated so I really just stick to the devel branch and forget all about the rest. Finally, let’s look at a snippet from my dist.ini which drives it all. Note that the CommitBuild Plugin must come before the @Git Bundle: [Git::CommitBuild] branch = release_branch = master message = <contents of latest changelog entry> [@Git] commit_msg = Bumped changelog following rel. v%v The CommitBuild Plugin is responsible for pushing the built distribution into a branch other than the one I’ve currently checked out. That is, I’m working in devel but the baked distribution is committed to master along with a nice comment, just at the same time as being uploaded to CPAN. Okay, I have one confession. Getting the contents of the Changes file entry into that message variable does involve a wee hack, but you could equally just say something like "product of release %v" using the Git Plugin substitution variables. I hope showing this has helped…. Continue reading →

Gentle reader, I need your advice. Some years ago I created the Net::Appliance::Session Perl module. It allows the user to automate interactions with CLI-based networked devices (think routers, switches) – a sort of Expect but with some helpful domain knowledge. The module has turned out to be quite popular (which is important to my story), in use by many organisations. There is a shopping-list of problems with the code, though, which makes both bug-fixing and feature development really hard. I’ve been planning a rewrite for over a year, and finally completed most of that in the past few days. The new version is completely different internally, but that shouldn’t matter much. The problem comes in that I’ve engineered a new "phrasebook" system for the scripted CLI interactions, and also the programmers’ API has changed. [Edit: I should add that lots of long-asked-for features are included, so the rewrite did bring benefits for the user.] Now, I guess that if I release this as Net::Appliance::Session with a major version bump it could cause havoc some time down the line when an innocent upgrades their server and in comes the new package and some maintenance script fails. Perl doesn’t make it easy to deal with this (nor do most operating systems, either, of course). However I’m loathe to change the module’s namespace. I like its name, and it feels like chasing my tail if I just rename a module to indicate an incompatible API change. Alternatively I could write a BackCompat role, but for starters that’s a lot of work (the old API was huge) and I worry that things like error handling simply work too differently in the new version to massage. Also, should that role be enabled by default or via a flag at use-time? I’m not a professional programmer, nor a key part of some large projects like Catalyst, Moose, DBIx::Class which I’m sure have had to deal with such issues in the past. I don’t really know the best course of action, and I also don’t have much communication at all with my user base (using this module is a sysadmin-practice "smell" so many don’t own up to it). I need your help: please have a think and let me know in comments what you might do in this situation. Many thanks!… Continue reading →

This note is to announce that I’ve just now, finally, removed the old CatalystX::ListFramework::Builder distributions from CPAN. Don’t worry, the module has long been deprecated in favour of its more popular replacement Catalyst::Plugin::AutoCRUD. This moment cannot pass without thanking Andrew Payne and Peter Edwards for creating the ancestor to them both, CatalystX::ListFramework. I believe Peter had the thought to provide some kind of simple web access to database tables, and prodded Andrew into creating the ListFramework. Whilst out at a miltonkeynes.pm meet one evening, I discussed forking the code to make it more automagical and to allow the use of an AJAX UI which Peter had good reason for not wanting at the time. And so ::Builder was born. I’m looking forward to the future of ::AutoCRUD. More time is available to me since I changed job recently, and there is a bunch of ideas waiting in the queue. If you have suggestions for AutoCRUD’s wishlist, please do create a simple RT ticket against the module…. Continue reading →