in reply to Re: Help with making a Module to reveal supported Perl versions
in thread Help with making a Module to reveal supported Perl versions

Thank you, davido! No, I didn't see Perl::MinimumVersion. While I haven't yet thoroughly examined it. It does seem to "fit the bill". Should I find something missing. I would surely simply attempt to add to it (by building upon the shoulders of that giant). :)

Thank you very much davido, for the excellent link. Much appreciated.
I can't believe I missed it. <blush>

--Chris

Yes. What say about me, is true.
  • Comment on Re^2: Help with making a Module to reveal supported Perl versions

Replies are listed 'Best First'.
Re^3: Help with making a Module to reveal supported Perl versions
by taint (Chaplain) on Dec 11, 2013 at 20:14 UTC
    Update:

    OK. I've had a bit of time to examine it (Perl::MinimumVersion) enough to evaluate to my perceived needs regarding the Module I had intended to create. Specifically; it lacks the ability to cross-reference calls/functions imported/exported by other Modules that your Module (uses|requires). It's difficult. Because, as I found last night File::Path is effectively in Perl. But the exports are different. For example. File::Path qw(make_path); was introduced in 5.8. But in order to achieve the same results in earlier versions. I discovered the export had to be File::Path qw(mkpath);. This would also work in versions newer than 5.6. But, being "legacy", will throw warnings during the "smoketest" cycle(s) on the CPAN.

    So. Perhaps my well-intentioned endevour is still valid. But would be better directed at an extension the the already existent Perl::MinimumVersion.

    Thanks again for your input.

    --Chris

    Yes. What say about me, is true.
[reply]

      Yes, that is a can of worms. Sometimes it's easiest to just look at the Changes files of the modules your module depends upon to see if you're using some feature that wasn't available in earlier versions. Then in your Makefile.PL specify a minimum version number for that module which will satisfy your use case.

      Dual-lifed modules are tricky too, but the process is similar.

      As a last resort you can upload a dev release of your module to CPAN and watch the FAIL reports roll in.

      The undertaking of determining what the earliest version of all dependency modules needs to be to support a given module on a given version of Perl is really hard. If you have the time, energy, and capability to do it right, be sure to put it on CPAN. If you don't have the time, energy, and capability to do it right, you are not alone. ;)


      Dave

[reply]
[d/l]

        davido, that is exactly the approach I took with Module::Cooker. I left out any minimum perl version and waited for FAILS to come in. The only one was on 5.6 so far and seems tied specifically to File::Path. make_path seems to have been introduced in F::P v2.06_2 so I am setting that in a prereq in Makefile.PL and going to see what happens from there.

        The only real annoyance is that in order to test on a given version I have to have a clean perlbrew install, and that can be problematic at times on a shared hosting server.

        It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
[reply]
[d/l]
        "The undertaking of determining what the earliest version of all dependency modules needs to be to support a given module on a given version of Perl is really hard. If you have the time, energy, and capability to do it right, be sure to put it on CPAN. If you don't have the time, energy, and capability to do it right, you are not alone. ;)"

        Quite right davido. I'm going for it. I think it'll save, when done correctly, and maintained, a great deal of time for developers, and be well worth the effort.

        Thanks for your reply.

        --Chris

        Yes. What say about me, is true.
[reply]

In Section Seekers of Perl Wisdom