Update dist.ini with the versions you have installed

My usual behavior for setting version requirements in dist.ini:

Go through each dep, search for it on CPAN, copy and paste the version number.

I decided that
a) that takes too long
b) That's not the versions I've been testing with.

So I hacked this together: dzil_myversions.pl

Synopsis

$ dzil listdeps | ~/dotfiles/home_bin/dzil_myversions.pl 
aliased = 0.31
Compress::Raw::Zlib = 2.062
Data::Dumper::Concise = 2.020
Encode = 2.54
ExtUtils::MakeMaker = 6.8
File::Spec = 3.40
HTTP::Request::Common = 6.04
IO::Async = 0.61
IO::Async::Loop = 0.61
IO::Async::Process = 0.61
IO::Async::SSL = 0.13

Pitfalls to avoid

Locally installed copies of things that aren't on CPAN yet.

5 Comments

Hi

I don't use dzil, but I too like to know which versions I'm actually using:

#!/usr/bin/env perl

use feature 'say';
use strict;
use warnings;

use File::Find;

use Perl::PrereqScanner;

my(%module);

# ----------------------

sub found
{
# Skip unwanted files.

return if ($_ !~ /\.(cgi|PL|pl|pm|psgi|t)$/);

# Skip the Module::Install inc/ directory.

return if ($File::Find::dir =~ m|^\./inc|);

my(@module) = Perl::PrereqScanner -> new -> scan_file($_) -> required_modules;
@module{@module} = (1) x @module;

} # End of found.

# ----------------------

find(\&found, '.');

my($version);

for (sort keys %module)
{
# mversion ships with Module::Version.

$version = `mversion $_`;

chomp $version;

$version = 'undef' if (length $version == 0);

say "$_ $version";
}

Blogged about the same thing a while back. I think choosing the currently installed version is the most sensible thing to do (and not to mention one of the easiest) as that version *is* what we're testing our module with.

It's also a good (responsible?) thing to update first to the latest version on CPAN. But sometimes I forget to do that.

Artificially setting the prerequisite version too high is not very friendly to users, where you are forcing them to upgrade when it might not be necessary. This may not be a big deal for some modules and distributions, but others change their internals between versions, and you could be incurring a large upgrade for someone when it is not needed.

Sadly, this unfriendliness has been a part of even the venerable ExtUtils::MakeMaker since forever: run "h2xs -AXn My::Module", and the Makefile.PL will claim that your module only runs on something at least as new as whatever version of Perl h2xs used. This is the new normal: do Chrome 75.3 and Mozilla 183.17.5 even run once a newer version has been released?

There's no doubt this is a difficult question.

Since I /don't/ automatically upgrade my laptop when new versions come out, this has the effect of helping protect end-users from needing to upgrade too.

And I do get feedback on versions which I try to implement immediately.

Leave a comment

About Samuel Kaufman

user-pic CTO / Codemonkey, Socialflow.com