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

[Diab Jerius]

On 8/8/21 4:26 PM, Dan Book wrote:
On Sun, Aug 8, 2021 at 3:35 PM Diab Jerius > wrote:


Howdy!

I've a module
(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

)

   "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



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 
.


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

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

[Diab Jerius]

On 8/8/21 5:47 PM, David Cantrell wrote:

On 08/08/2021 20:34, Diab Jerius wrote:


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

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?


You can check what's already installed in your Makefile.PL or 
equivalent, and prompt the user if you can't figure out what to do 
automatically. I ASSume that the correct thing to do would be to do as 
you currently do if none of your deps are installed, but if any are 
installed you'd want to tell EU::MM's WriteMakefile function that you 
have a runtime requirement for updated versions.


Use the prompt() function from ExtUtils::MakeMaker as that will pay 
attention to the PERL_MM_USE_DEFAULT env var. You may also want to pay 
attention to AUTOMATED_TESTING and NONINTERACTIVE_TESTING. In 
particular you will find that CPAN-testers generally set all three of 
those.


Vary as appropriate if you use a different build system.

This is good advice.  I'm ambivalent about prompting the user when the 
functionality is optional. I've also had varied success when using 
installers such as cpanm with prompts & warnings, as there's a lot less 
info presented to the user.


What I should probably do is split the distribution into core and 
optional components.


Thanks!

Diab

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

[David Cantrell]

On 08/08/2021 20:34, Diab Jerius wrote:


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

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?


You can check what's already installed in your Makefile.PL or 
equivalent, and prompt the user if you can't figure out what to do 
automatically. I ASSume that the correct thing to do would be to do as 
you currently do if none of your deps are installed, but if any are 
installed you'd want to tell EU::MM's WriteMakefile function that you 
have a runtime requirement for updated versions.


Use the prompt() function from ExtUtils::MakeMaker as that will pay 
attention to the PERL_MM_USE_DEFAULT env var. You may also want to pay 
attention to AUTOMATED_TESTING and NONINTERACTIVE_TESTING. In particular 
you will find that CPAN-testers generally set all three of those.


Vary as appropriate if you use a different build system.

--
David Cantrell

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

[Dan Book]

On Sun, Aug 8, 2021 at 3:35 PM Diab Jerius  wrote:

> Howdy!
>
> I've a module (
> 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
> )
>
>   "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
>
> 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.

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.

-Dan

(resent to list)

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

[Diab Jerius]

Howdy!

I've a module 
(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)


|||"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

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?

Thanks,

Diab