On 8/8/21 4:26 PM, Dan Book wrote:
On Sun, Aug 8, 2021 at 3:35 PM Diab Jerius <djer...@cpan.org <mailto:djer...@cpan.org>> wrote:


    I've a module
    which may use JSON and YAML writers.

    For JSON, I use JSON::MaybeXS.  Cpanel::JSON::XS >= 3.0236 is

    My code can use either YAML::XS or YAML::PP.  YAML::XS >= 0.67 is

    Since JSON & YAML output are optional, I've encoded the XS
    dependencies as runtime recommendations, rather than requirements.
    JSON::MaybeXS is specified as a runtime dependency (as is
    YAML::PP, but that's a mistake; it should also be a runtime

    Here are the relevant bits of  META.json

           "runtime" : {         "recommends" : {            "Cpanel::JSON::XS" : "3.0236",            "JSON::PP" : "0",            
"YAML::XS" : "0.67"         },         "requires" : {            "JSON::MaybeXS" : "0",            "YAML::PP" : "0",         }      },

    Here's the problem, illustrated by this CPAN testers failure:


    The smoker has versions of Cpanel::JSON::XS and YAML::XS which are
    older than my required versions. Since the ::XS versions are
    prioritized over the ::PP versions, the code uses those and thus
    fails the tests.   I presume that because the ::XS versions are
    recommendations rather than requirements, they weren't updated to
    the versions that the code requires.

    Is there some way of triggering an update to the required versions
    via the metadata, or should I put a runtime version check into the
    tests and skip if the appropriate versions aren't installed?

    For production runs, I'll have to add a runtime check in the code
    which falls back to YAML::PP if the version of YAML::XS is too
    old, but I don't see how I can do that with JSON::MaybeXS, as
    there are no hooks to indicate acceptable versions of the
    backend.  I think my only option is to take the same approach as
    for YAML, namely manually specifying which backend libraries are
    acceptable.  I don't like this, as now I can't automatically take
    advantage of JSON::MaybeXS's list of backends.

    Any advice on how to gracefully handle this situation?

There's only two real options, and you might want to do both:

Dynamically add a runtime requires on the required version if you detect that the optional module is installed but too old. With dzil you can do this with https://metacpan.org/pod/Dist::Zilla::Plugin::DynamicPrereqs <https://metacpan.org/pod/Dist::Zilla::Plugin::DynamicPrereqs>.

At runtime, ensure that the module satisfies your minimum version if it is present, and if not treat it as if it was not installed.

I'll take a look at DynamicPrereqs. My concern is that if a user isn't interested in the optional component, this adds an unwanted dependency.

To get this out  the door I've added the runtime fallback checks in the code and made the tests conditional on the runtime checks succeeding.

As I mentioned in my response to David Cantrell's email, the real solution is to split the distribution into core and optional components.



Reply via email to