Re: How to handle minimum versions of dependencies which are recommended but not required?

On 8/8/21 4:26 PM, Dan Book wrote:
> On Sun, Aug 8, 2021 at 3:35 PM Diab Jerius <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Howdy!
>
>     I've a module
>     (https://metacpan.org/release/DJERIUS/Data-Record-Serialize-0.27-TRIAL
>     <https://metacpan.org/release/DJERIUS/Data-Record-Serialize-0.27-TRIAL>)
>     which may use JSON and YAML writers.
>
>     For JSON, I use JSON::MaybeXS.  Cpanel::JSON::XS >= 3.0236 is
>     required.
>
>     My code can use either YAML::XS or YAML::PP.  YAML::XS >= 0.67 is
>     required.
>
>     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
>     recommendation).
>
>     Here are the relevant bits of  META.json
>     (https://metacpan.org/release/DJERIUS/Data-Record-Serialize-0.27-TRIAL/source/META.json#L98
>     <https://metacpan.org/release/DJERIUS/Data-Record-Serialize-0.27-TRIAL/source/META.json#L98>)
>
>            "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:
>
>         http://www.cpantesters.org/cpan/report/2f961e48-6bf6-1014-90df-a468c69b7236
>         <http://www.cpantesters.org/cpan/report/2f961e48-6bf6-1014-90df-a468c69b7236>
>
>     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.

Thanks!

Diab