Bug #133205 for CPAN: Experimental 'recommends_policy' option, turned on by default, leads to surprises for users

The man page for CPAN.pm (e.g., https://metacpan.org/pod/release/ANDK/CPAN-2.28/lib/CPAN.pm) lists these two configuration variables: ##### recommends_policy whether recommended prerequisites should be included ... suggests_policy whether suggested prerequisites should be included ##### This man page provides no further documentation of these policies. One has to go deeper into the distribution, to lib/CPAN/FirstTime.pm, to find a more complete description: ##### recommends_policy (Experimental feature!) Some CPAN modules recommend additional, optional dependencies. These should generally be installed except in resource constrained environments. When this policy is true, recommended modules will be included with required modules. ... suggests_policy (Experimental feature!) Some CPAN modules suggest additional, optional dependencies. These 'suggest' dependencies provide enhanced operation. When this policy is true, suggested modules will be included with required modules. ##### These features appear to have been added to the CPAN distribution around 2013, which means that they have been shipping with the Perl core distribution since 2014. Now, when I see some functionality described as an 'Experimental feature', my assumption is that it is turned OFF by default and that if I want to use it I have to type some code that turns it ON. For example, if in perl-5.32, I want to use the 'lexical_subs' feature, I have to say: "use experimental 'lexical_subs';". 'suggests_policy' is turned OFF by default, but 'recommends_policy' is turned on. Granted, you do have that statement there say that 'recommends' modules should be installed except where resources don't permit. But you don't explicitly say that this is turned ON by default (which I would guess means that 'y' is the default choice in the installation script). For me, this has repeatedly had adverse consequences which have caused me to generally prefer 'cpanm' as my installer over 'cpan'. In my attempts over recent years to provide another approach to the "Blead Breaks CPAN" problem, I have run a program, "CPAN River 3000," in which I attempt to install 3000 CPAN distributions against a monthly development release of perl -- and install them in dependency order. So the guts of that program essentially is: ##### cat list-of-3000-modules | xargs ./bin/cpanm ##### ..., then parse the .cpanm build log and analyze results. 'cpanm' apparently does *not* attempt to install modules listed in a distro's 'runtime:recommends', 'runtime:suggests' or similar metadata stanzas. So that means that the modules actually installed against a monthly perl release very closely track the list of 3000 modules I feed to 'cpanm'. In particular, it means that if I do not want a particular distro to be included in the list of 3000 modules (say, it times out too much during testing or goes into infinite loops), then it's not very difficult for me to exclude it and to exclude its reverse dependencies as well. I run no risk of pulling in a badly behaved distro that happens to be listed in another distro's 'runtime:recommends' or 'testing:recommends' metadata. In simple terms, 'cpanm' DWIMs. 'cpanm', however, turns out to be much less 'strict-compliant' than 'cpan'. In Perl 5 this is of little consequence. But suppose I'm working on a future version of perl in which strict is turned on by default. In other words, suppose I'm working on a leading candidate for Perl 7 (https://github.com/atoomic/perl/issues/153). It turns out that 'cpanm' so far fails with Perl 7 for a variety of reasons. And since it's code is fat-packed, it's not easy for someone not named Miyagawa to hack on it. Miraculously, 'cpan' works with Perl 7 right out of the box. So the first time I went to try to install CPAN modules in dependency order (a "CPAN River 200" rather than a "3000") against a Perl 7 executable, it Just Worked! Well, it worked until I got to SOAP::Lite, which is #520 in my most recent calculation of the CPAN River. SOAP::Lite has many modules in its 'recommends' and 'suggests' section. 'cpan' manages to install SOAP::Lite and then -- since, by default, CPAN::FirstTime's 'recommends_policy' is ON by default -- it proceeds to try to install all the distros in its 'runtime:recommends' section -- and *their* dependencies -- until it gets to 'mod_perl'. And there all hell breaks loose. See: https://rt.cpan.org/Ticket/Display.html?id=131952#txn-1909221. Also, at this point see the plain-text file I am attaching to this ticket which provides data about side-by-side attempts to install SOAP::Lite with 'cpanm' and 'cpan'. Recommendations: * 'recommends_policy' and 'suggests_policy' have presumably been "experimental" for 6 years now. Perhaps it's time to reconsider their status. * Regardless of whether 'recommends_policy' remains experimental or not, it should be set to OFF by default. This would require revision of the documentation in CPAN::FirstTime above, and it would require a *one-character* code change at line 956 of lib/CPAN/FirstTime.pm. (I can supply a pull request upon request.) * If for some reason you want to continue to have 'recommends_policy' set to ON by default, then that decision should appear in the Config Variables section of CPAN.pm (https://metacpan.org/pod/CPAN#Config-Variables). It should not simply be buried in CPAN::FirstTime. * I install perls for testing purposes *many* times a week, using a shell script to do so. That shell script uses a 'wget' to fetch and install 'cpanm' immediately after it installs perl. If I am to use 'cpan' in a similar manner, then I need a shell one-liner that I can include in my shell script that immediately turns 'recommends_policy' OFF for any CPAN.pm or 'cpan' I install. Can you provide me with such a one-liner? Thank you very much. Jim Keenan