On 09-Nov-16 19:11, Dan Book wrote: > On Wed, Nov 9, 2016 at 9:49 AM, Timothe Litt <tlhack...@cpan.org > <mailto:tlhack...@cpan.org>> wrote: > > cpan and cpanm seem to handle 'recommended' differently. IIRC, > neither > defaults to installing 'recommended' modules. > > > Sadly, this is correct and in fact (as far as I know) CPAN.pm still > handles recommended prereqs completely wrongly if you do enable them > (fails the installation if they don't install). cpanm handles them > more correctly but still not ideally. The fact they are not installed > by default, in turn, makes them not any more useful than 'suggests' in > practicality, so it ends up being a semantic difference. 'recommends' > should be modules which are always a good idea to install but not > required, and 'suggests' should be modules which the user may consider > installing if they choose. > And this presumes that the person running the install knows enough to "consider." Which is fine if you're coding Perl. Not so obvious if you are trying to use someone else's package, which may silently fall back to crippled mode "because it's better than nothing". I see this all the time with a package I distribute, where people who install it can't spell P u r l. Oh, there's an 'e'? I've had to shell script the mechanics of bootstrapping that package onto a system that's never seen Perl.
> This leads to the case as you noted with JSON::MaybeXS, where the only > practical solution in the current state of things is to instead rely > on dynamic dependencies, and add a hard dependency on the modules that > are appropriate at installation time. Dynamic dependencies however are > a very widely supported and backwards compatible system. Only > configure-time dependencies are read from the static META.json, the > rest are read from the generated MYMETA.json, generally even if > dynamic_config is set to 0, though in that case it is imperative that > the generated prereqs match the static ones. But leaves the original issue unresolvable: MetaCPANdeps can't figure out what's really required. As Karen noted, once you set the 'dynamic' flag, all bets are off. And as you point out, the user experience is less than ideal. As a user, all I want is to type "install this_thing_that_I_want", and not worry about "suggests", "recommends", or any thing else. The baggage ought to come without effort and excess baggage fees. (I know, retrograde thought.) As an author, I want to be able to specify what I need without writing Perl that invalidates the tools that sort out dependencies. Even if MetaCPANdeps decided to install every module to see what it *REALLY* required, it could only know in the tested environment. The user tools (cpan, cpanm) can't answer the question "If I want this package, what would I need/install?" without actually installing in the real environment. My observation that a language is probably required to solve was only partly tongue in cheek - at least it could let the user tools provide an accurate answer. MetaCPANdeps could at least provide a symbolic answer - resolving the symbols for static dependencies, and providing the equation of what's left with the unresolved symbols. (Pass 2 would make it prettier...) I don't claim to have a complete view or solution. But I'm pretty sure that David's suggestion to toss grandkid (and great-great grand cousin three times removed?) require/suggest/hope&pray into META is not enough to make a real dent in the problem. I hate to disagree with Karen, but the swamp really is a bad as I think - once you understand that your audience isn't just people who know what the Camel book is, much less read it. It's also people with other priorities, and tools for those people. Sigh.
signature.asc
Description: OpenPGP digital signature
