Writing version of dependencies
Sometimes excess laziness is not a virtue. Whenever I add a dependency, I used to just write in dist.ini:
Foo::Bar=0This is of course not correct. Starting from last week, I've changed this habit. now I write the version which was currently installed on my development laptop/PC at the time of writing. And if I am not lazy, I try "cpanm Foo::Bar" first to update it to the latest version.
A programmer (mostly Perl 5 nowadays).
My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.
But do your users really need the same version of Foo::Bar as you have? Perhaps an earlier version of Foo::Bar will work just fine.
My usual technique is to specify version 0 of dependencies unless I'm aware of a particular case where it makes sense to require a higher version. For example, for MooseX stuff I generally depend on 2.00 because I know that a lot of the Moose internals changed between 1.x and 2.x. Or depend on XML::LibXML 1.70 because I want to use the
load_xmlmethod.Yes, this occasionally results in CPAN testers failures, and/or bug reports. But then you just respond to the bug report with "upgrade to Foo::Bar version 0.61" and add that version to the dependencies of your next release.
If you're going to ship your module to CPAN, that might not be the best idea. Setting the minimum version to whatever is installed on your machine might force downstream users to upgrade things unnecessarily. It makes your life as a module maintainer easier, but it could make your users suffer.
My (ideal) strategy is to set the minimum version to zero until I know that there is some reason to require something newer. Then I rely on CPAN Testers to help me flesh that out. To minimize pain for users, I would first ship a development release. If the CPAN Testers don't find any dependency problems, then go ahead with a production release.
This strategy isn't foolproof. Some CPAN Testers always use a clean perl for each test, so they end up testing the latest versions of your dependencies anyway. It's also a lot of work to manage, and it's not fun to wait for test results before making a production release. So I don't always follow this strategy myself.
I'm hopeful that alpha.stratopan.com can somehow help with matching modules to the right version of their dependencies. But for now, it just keeps the dependencies for you -- it is up to you to decide which versions you want.
YMMV
Hi Steven
Another approach is to use one of the scripts shipped with Module::Metadata::CoreList, which allows you to pick a version of Perl and get the matching version of a module which shipped with that Perl.
Oh yes, I do specify minimum Perl version and then check with the 'corelist' utility to see if the module I'm using is already in core for that Perl version. In fact, I run lint-prereqs in my release script, so that extraneous dependency (stating as dependency some module which is already in core) prevents the release.
Correct, ideally we should find the true minimum version. However, if we lack the time to find that out, or don't want to deal with old/buggy dependencies, making sure the user has the same version of dependency as us authors is the next best thing, IMO.
Hi Jeff,
You brought a good point (and one that should've been obvious to me). More than half of the time, I'm actually specifying modules that I authored myself as a dependency, so perhaps that's why I don't think enough about other people's modules.
But you also mentioned a good reason why just specifying the latest version has its pro's. Perhaps I need to balance things out: for modules that (potentially) a lot of people will depend on, where stability is important, I'll spend the extra time to specify the exact minimum version. For other stuffs, I'll just specify the latest version or the one on my computer.
My perl version is pretty conservative anyway (it's whatever Debian stable or testing is shipping).
I flip flop on this. For awhile I did it your current way, but I got more complaints that way. Now I only set the minimum version if I know that I must have at least that version for a feature or bug fix.
I wish we had a way to have an undef version to mean that I don't know what it should be or I'm not specifying it.
I've been back and forth on this. Currently I specify whatever I use. That is to say if I
use Foo;I specify dependencyFoo => 0. If Iuse Foo 1.2;I specifyFoo => 1.2. The use of a version is driven by bug fixes, features, and user feedback.But I typically specify core dependencies as well. It is rare for modules to be dropped from core, but it is not unknown.
Not so rare. Looking at perlXXXdelta PODs, modules are routinely being removed from core :) But 'corelist' can help you decide, for example:
But perhaps consider avoiding such modules anyway.
Once upon a time many years ago, declaring dependencies on core modules was problematic because CPAN.pm had a bug and might try to upgrade your perl. But that was then; the bug has been fixed roughly forever. You should never not declare a dependency, even if it is on a core module.
After almost a year, turned out that my habit hasn't changed for the most part. I still write 'Foo=0' and only specify version on rare occasions. I guess laziness FTW!