Version Dependencies: Don't Guess!

| 3 Comments

I'm glad to see Ævar's The CPAN client version-less dependency problem, because it discusses a real problem. In the absence of specific information about dependencies, what should installers do?

Unfortunately, that's the wrong question.

Have you ever read code which performs user input validation deep in its guts, way down in code which has layers of insulation between user input? I have. I take no small pride in removing this validation code and putting it where it belongs: as close to the input as possible. This has at least two benefits. First, it allows for the possibility of reporting user errors in the view and dispatch logic, where it belongs. Second, it removes clutter from code which can document its expectations appropriately.

(I realize that high security applications may need extra paranoia and I submit that you should have effective testing of the interfaces between components to satisfy you that unrealistic data never enters the application, but it's still a general rule.)

If you're confident that you've dealt with all sources of errors before a certain point, don't worry about them after that point.

With that all said, perhaps the client side of the CPAN installation is the wrong place to handle these dependencies. After all, the developer of the code has presumably installed dependencies locally and has run tests against them. Why shouldn't Module::Build or ExtUtils::MakeMaker check the installed version when bundling the distribution and include that as a recommended minimum version in the META.yml file?

It's no worse than "Install whatever version you want" and it at least has the data point that someone had that version working. It also requires no changes to the installers with fragile or odd heuristics.

3 Comments

I think that if the build tools (Module::Build, or ExtUtils::MakeMaker, or Dist::Zilla) are to check installed versions of dependencies when it is not provided, it should be not as minimal version, but as a soft dependency: recommended version or simply tested version when bundling. Though I suspect that META.yml / META.json would have to support such soft dependencies (known to work with dependencies).


I guess that what you wanted to say, but it was not entirely clear to me...

What if you have multiple interfaces? wouldn't it be appropriate to put the validation at the central point that both access to do work?

Being a heavy CPAN tester, I think that specifying the author's
version as the minimal version does not buy you anything. Breakage can
occur in both directions: the dependent module could be too old, but
it could also be too new (e.g. changing its API or introducing new
bugs). Even with exactly the same module version breakage can occur,
for example if problems occur on a different operating system than the
author's one, or with different perl versions.

Also I think that a specified version in PREREQ_PM is actually
valuable information. It probably means that the author read the
ChangeLog of the dependent module to find out the required minimal
version; or that some actual bug with an older dependency was reported
and fixed.

And why do you think there could not be additional support in the CPAN
clients? CPAN.pm has already the functionality to install the newest
module. So maybe it would be not too hard to have an option to always
install the newest version instead of keeping old ones.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on October 7, 2010 3:05 PM.

Structured Data and Knowing versus Guessing was the previous entry in this blog.

Certification or Delivery is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Powered by the Perl programming language

what is programming?