Dist::Zilla::Plugin::EmailNotify and not releasing to CPAN

We've been using Dist::Zilla at $work quite some time now.

For a while I feared the possible mistake of running "dzil release" on one of our modules or applications (we have quite a bit!) and thus releasing it to CPAN. We try to remove all generic parts of our code and push it as regular modules on CPAN so everyone can enjoy it (and we get feedback and patches and so on). This means that the rest of our code, what we keep on local repositories, are very specific to us. This cannot be released, obviously.

First job was fixing that. Easy enough. In your dist.ini:

[@Filter]
-bundle = @Basic
-remove = UploadToCPAN

Now if someone tries to release, it fails. Yay!

Next one was a feature I wanted for a while: to be able to get notified by email when a new release it out. I've searched CPAN and could not find anything that emails. So I wrote Dist::Zilla::Plugin::EmailNotify.

What it does is allow you to add the following:

[EmailNotify]
from = admindevs@company.gtld
recipient = sawyer@company.gtld
recipient = erez@company.gtld

... and when you run 'dzil release', it will send an email to the list saying a new distribution has been released. This helps me know when new versions of modules and applications I don't develop are being released by their maintainers. While we do have meetings (daily, and tri-daily) in the development team (and beyond), we can't all always be up-to-date on every release (or dev release) and these emails help.

In the future, I want to hook Dist::Zilla::Plugin::EmailNotify to some Changes file parsing and be able to throw the changes in there. Maybe add a flag for asking input from the user on release to describe the changes so users could say "notify, but ask me what the changes are". I also want to make the release text a template in a variable (so others could override it) or in a configuration somehow.

4 Comments

Just a side note...

For release hooks, instead of writing a dzil plugin, I find it less of a hassle nowadays to just use DZP::Run::Release and execute whatever command-line command I want.

(There's also DZP::Run::{BeforeRelease,AfterRelease,BeforeBuild,AfterBuild}.)

Well, you can hook into AfterBuild then. Or redefine what "release" means for private dists. (We also manage private dists with dzil, and "release" means saving the tarball file to an internal server.)

Leave a comment

About Sawyer X

user-pic Gots to do the bloggingz