Inconsistent version for Crypt::SSLeay

[markmontymark]

Hi,

I am taking part in the CPAN Pull Request Challenge and I was given Crypt-SSLeay to take a look at. I looked at the CPANTS page for Crypt-SSLeay, and it shows a Core Metrics failure for 'consistent version'.

The versions in Crypt-SSLeay are:
lib/Net/SSL.pm $VERSION = '2.86';
SSLeay.pm $VERSION = '0.76';

The history of Net::SSL is tracking a different revision history than Crypt::SSLeay. I think that coupling Net::SSL's versioning with Crypt::SSLeay doesn't allow for N different modules to provide a singular, M module contract. Did that make sense? Put another way, if package A, B and C want to provide an implementation for package "SomeConcept", then all versions inside each individual package would have to align with SomeConcept's version.

So, my question for you is, is this something you would welcome a PR for? I have started on a PR, but wanted to see what you thought (or your experience) of this situation.

Thanks,
Mark

[karenetheridge]

I'm curious what changes you have in mind for your PR...
but it seems to me that since inconsistent versions are actually intentional in this distribution, it would be a usecase for the x_cpants metadata as sketched out in cpants/www-cpants#39.

[markmontymark]

Wasn't aware of x_cpants metadata. That does like a good approach, because it allows a module author to explicitly state version differences.

I had a heurisitic in mind that would do something like:

• for each package
  • store base package name in hash with key ( ($base) = $package = m/^(.*?)::/) and value is hash of versions
• Loop over base package names, if any base package has more than one version, then report as inconsistent error.

Example,

Ok inconsistent version
Net::SSL 2.86
Crypt::SSLeay 0.76

would yield,

{ 
   Net => {"2.86" => 1},
   Crypt => {"0.76" => 1}
}

Not Ok inconsistent version
Acme::Error 1.0.3
Acme::Error::Bad 1.0.2

would yield,

{ 
   Acme => {"1.03" => 1,"1.02" => 1 },
}

Where this becomes a problem is with packages publishing a 'Bundle::' package, which is why I said 'heuristic'. Might need some shims for things like "Bundle". But, I like the idea of x_cpants metadata instead of trying to be too smart in SiteKwalitee/Version.pm

[karenetheridge]

Wasn't aware of x_cpants metadata

Well it's vapourware still, so you can't use it yet :)

I think you're making assumptions about namespaces that aren't valid. Acme::Error::Bad and Acme::Error don't necessarily have more things in common than Acme::Error and Acme::Success. Perl namespaces just don't work that way -- although we often group things in heirarchies, sometimes two totally different things share a partial namespace, or two related things might have different namespaces.

For the purposes of this kwalitee metric, I think what it's currently doing is correct - checking all namespaces provided by the distribution, and flagging an error if any of them have a different version than any of the others.

[charsbar]

Generally speaking, module versions in a version of a distribution should be consistent and should be the same of the version of the distribution regardless of the nature of modules in it, because otherwise it's harder to determine which version of distributions should be fetched to install if module versions are different from distribution versions (note that what's listed in Makefile.PL/Build.PL/cpanfile is module names and their versions, not distribution names and their versions, and what CPAN installers actually need is distribution names and versions).

For example, Crypt-SSLeay distribution version 0.68, 0.70, 0.72 have the same Net::SSL version 2.86. When Net::SSL 2.86 is listed in A distribution's Makefile.PL etc, CPAN installers (CPAN, CPANPLUS, cpanminus, and others) consult an external source to determine which version of Crypt-SSLeay distribution should be installed. They usually install the most recent version (in this case 0.72) among the candidates.

Then, what if you happen to find a new Crypt::SSLeay is released with a fix in Net::SSL, via Twitter/Facebook/IRC for example? Probably the news only tells you the version of Crypt-SSLeay distribution. You can find the version of new Net::SSL if you actually install it and see its source or run a oneliner to show its version, or maybe you can visit search.cpan.org (which shows module versions as well. MetaCPAN does not as of this writing). However, you can't simply update the required version of Net::SSL with the new version of Crypt-SSLeay distribution. Not good, from the users' point of view, isn't it?

As for x_cpants meta field, it's been implemented though not advertised. It's currently to ignore specific metrics (use_strict, use_warnings) for a very good reason. It might become applicable to other metrics in the future, but I don't think this metric is a good candidate.