CPAN Archives

I've uploaded a major release of Constant::Export::Lazy

I created Constant::Export::Lazy a while ago to consolidate the main constant exporting module at work into something even better. I've just uploaded a major release which allows for adding all the features that I can reasonably think of being useful for a lazy constant exporting module.

It can now support something like Exporter.pm's %EXPORT_TAGS, along with numerous other improvements. I also toiled a bit at it with Devel::Cover and it has 100% test coverage now. In the progress of achieving that I found a few minor bugs that I fixed.

In implementing this module I tried to avoid adding narrow specific features (like %ENV overrides, or support for %EXPORT_TAGS), and instead added more general callbacks that make those features and others I haven't even thought of yet possible.

For why I needed to write the umpteenth constant creation module on the CPAN instead of using something that already exists see the rationale in the documentation.

This module's already been stable for a while and I see no reason why I'd introduce any breaking changes to it. If you'd like an easy-to-use constant defining module that you can use in multiple mutually incompatible environments give it a shot.

The CPAN client version-less dependency problem

An interesting topic came up on #distzilla. Most modules depend on other modules, but some don't depend on an explicit version. So if you use the module with an ancient version of one of its dependencies it'll break, because the author never tested that version.

We've probably all run into problems as a result of this and grudgingly upgraded the dependencies as a result, but could CPAN clients handle this better?

Technically they're doing the right thing already. The CPAN clients are unable to distinguish between "explicit 0", "any version will do" and "author didn't say".

  • Some don't specify versions at all. I mostly fall into this camp.
  • Even if you specify a version for every dependency it's really hard to get it right. You might accidentally use some API feature in a dependency that doesn't match the feature set of your declared version.
  • Even if you get it 100% right it's all for naught if one of your dependencies isn't as careful about its dependencies.

So what would be a better heuristic? Some suggestions:

  • Make sure that dependencies aren't much older than the module that requires them. Something in the spirit of:

    Are you sure you want to install this shiny new version of Web::Some::Thingy but still use your 4 year old copy of DBD::SQLite? Install the new DBD::SQLite? [Y/n]

  • Query some publicly available submission system like the CPAN metabase:

    You're trying to install Web::Some::Thingy with a 2 year old DBD::SQLite, but test results show that you need the 6 month old version not to get test failures. Install the new DBD::SQLite? [Y/n]

I should reiterate that CPAN clients are doing the right thing already with regards to the relevant standards. But it can be useful to also account for the human factor.

Update: chromatic pointed out on the Modern Perl Books blog that you could set the recommended minimum version to whatever the developer happened to have installed when testing the module (and I'm replying here since it seems that his OpenID method is broken).

I think that alternative is probably the worst of the lot, some CPAN authors do that and it causes all sorts of problems for people using downstream distributors of the CPAN.

For example if you develop on v5.13.5 as I do, and depend on Test::More you'd implicitly depend on version 0.97_01 using this method. Even though the 0.92 version included with perl v5.10.1 would probably do just fine.

By depending on the latest version someone trying to use your program with Debian, RHEL or other third-party package systems will run into problems. Uers show up on IRC all the time with this problem, and more often than not the answer is "ignore the prerequisite versions, your old module will work just fine". At best they're using the CPAN directly, and will have to needlessly upgrade & test a lot of their dependencies.

Adding automatic soft dependencies as one commenter points out would probably be more useful.

But either solution would require awareness and diligence by CPAN authors, and new releases of the offending distros. Given the human factor of this problem a change in the CPAN clients would probably work better, and would trickle down to existing releases.

About Ævar Arnfjörð Bjarmason

user-pic Blogging about anything Perl-related I get up to.