Could Module::Build::Tiny version requirement be more conservative?

[pghmcfc]

Currently the plugin generates a dependency on the same version of Module::Build::Tiny that the module's author is using. Usually this is the latest and greatest version, resulting in downstream users having to update to that version. Would it not be possible to default to some reasonable version and only require a later version if the specific module needed something from that later version? This would be on a par to Dist::Zilla generating requirements for ExtUtils::MakeMaker version 6.30 by default.

The current situation is problematic because, for instance, versions of Module::Build::Tiny after 0.028 require TAP::Harness::Env, from Test-Harness 3.29. The beta release of Red Hat Enterprise Linux 7 (full release not due until later this year) is shipping with Test-Harness 3.28, so without replacing part of the vendor's perl stack, it's not possible to update Module::Build::Tiny beyond 0.028, which is "old" already :-( It's usually possible for downstreams that have to live with these restrictions to patch out the version requirement without problems, but it would be nice not to have to do that.

By the way, it's unlikely that Red Hat would respond favourably to a request to update Test-Harness because of the amount of testing they'll already have done with the current version and the next version up having some (albeit minor) API changes.

[Leont]

Would it not be possible to default to some reasonable version and only require a later version if the specific module needed something from that later version?

That would be awesome, but sadly that would also be very difficult to detect. [MakeMaker] and [ModuleBuild] get away with what they do because those tools are pretty much in maintenance mode (new features are relatively rare), Module::Build::Tiny isn't quite (though it's getting there).

If I really had to set a version, it would currently be 0.030, as there are dists out there that wouldn't work without the include path logic.

The current situation is problematic because, for instance, versions of Module::Build::Tiny after 0.028 require TAP::Harness::Env, from Test-Harness 3.29. The beta release of Red Hat Enterprise Linux 7 (full release not due until later this year) is shipping with Test-Harness 3.28, so without replacing part of the vendor's perl stack, it's not possible to update Module::Build::Tiny beyond 0.028, which is "old" already :-(

I suspect the easiest solution is to hack up a TAP-Harness-Env package containing only that class, and make your Module-Build-Tiny package depend on that. But that may not be a solution if you want everything to work out of the box using only vendor packages (not sure if this is your goal).

Though really, if you're worried about "replacing part of the vendor's perl stack", you should consider building your own perl and leave the system's perl to itself.

[karenetheridge]

...or install your extra dependencies in a local::lib... In general, expecting everything to be provided in the vendor perl is the wrong way to go.

[jkeenan]

Leont wrote: "Though really, if you're worried about "replacing part of the vendor's perl stack", you should consider building your own perl and leave the system's perl to itself."

I agree. Treat the vendor-supplied perl as existing primarily for the system's own needs. To manage your own perl needs, either (a) install a recent release of perl into (usually) /usr/local or an equivalent location; (b) build your own perl from source and similarly install it; or (c) go the perlbrew/local-lib/cpanm route.

[pghmcfc]

I understand that maintaining your own stack of perl and whatever modules are needed for a given application is the best approach for stability and flexibility, though there is a downside in that you need to keep on top of security issues for everything in your stack yourself rather than relying on the vendor to do that for you.

However, some of us downstreams face constraints that prevent us from doing that. From time to time I read on perl blogs about people even having to maintain code running on early 5.8 releases and not being able to upgrade things. The restrictions that I face as a Fedora and EPEL packager are that the packages I'm creating are to enhance the existing vendor's stack and cannot replace or conflict with it. This isn't a big problem in Fedora as we can generally keep up reasonably well with upstream in most cases, but for EPEL we really have to work with what we've got. I'm used to having to add patches for back-compatibility but it would be nice not to have to do that for the latest release that isn't even out yet ;-)

Regarding Leon's suggestion of making a TAP-Harness-Env package, I think that's worth a try and I'll have a look at it. There's a precedent for that too, as we had a TAP-Harness package to complement the old Test-Harness package that pre-dated the merging of TAP-Harness. Thanks for that idea.

[Leont]

However, some of us downstreams face constraints that prevent us from doing that. From time to time I read on perl blogs about people even having to maintain code running on early 5.8 releases and not being able to upgrade things.

I don't understand how people are not be able to upgrade things but at the same time expect the latest dependents to work out of the box. It's unfortunate how this case triggers that very early in your cycle, but this sort of issue is bound to happen more often.

[karenetheridge]

On Wed, Feb 19, 2014 at 12:09:04PM -0800, Leon Timmermans wrote:

I don't understand how people are not be able to upgrade things but at the same time expect the latest dependents to work out of the box.

That's the bit I don't understand too. If you're updating one thing, why
can't you update more than one thing at the same time? [1] And if you're not
updating at all, you don't need to be concerned about what subsequent
releases are doing, because you're not using them.

[1] for example: if you need Foo 2.0 on your system and you've only got
1.0, why not make a carton file (or just a self-contained local-lib
tarball) that contains Foo 2.0 and all its dependencies?

[pghmcfc]

I don't understand how people are not be able to upgrade things but at the same time expect the latest dependents to work out of the box. It's unfortunate how this case triggers that very early in your cycle, but this sort of issue is bound to happen more often.

What may be the latest thing now is just another old version in a few years' time. Say for instance I was using a module Foo 1.0 in an application and after being deployed for a couple of years I get a bug report about some corner case and track it down to an issue in Foo. In the meantime, Foo has had releases 1.1, 1.2, 1.3, 1.4, 1.5, 2.0, 2.1 etc. and the issue I'm having is actually already known about and fixed in Foo 1.2. So I'd like to update to Foo 1.2, which has no API changes, new dependencies or incompatibilities, but now requires a later version of M:B:T to build it, which in turn does perhaps want to pull in new modules that have such issues.

I'm not asking that new dependencies aren't added to modules as they progress, just that if possible, not to add dependencies that aren't real. If M:B:T isn't sufficiently stable or feature-complete yet to that, then fair enough, keep bumping the version requirements. But please keep in the back of your mind my request to stop the version bumping treadmill when a point of such stability is reached, however far out that may be. It'll keep at least some of your downstreams happy :-)

[Leont]

But please keep in the back of your mind my request to stop the version bumping treadmill when a point of such stability is reached, however far out that may be.

I'm open to having an additional heuristic to detect the minimum version of MBT needed to build this dist, but that's a bit tricky/unreliable (as is any heuristic). At first glance it looks something like:

• If .PL files are present in lib, require 0.039
• If using XS, require 0.036
• For a top-level module name, require 0.019
• For sharedirs 0.014

This list may grow in the future, though.

[Leont]

I've released a new version with a «version_method = conservative» argument that does pretty much what I described above. I might make it the default at some point in the future, but it would have to prove itself first.

[Leont]

This has been made the default in 0.011 :-)