Re: Declaring optional dependencies

On 09-Nov-16 19:11, Dan Book wrote:

> On Wed, Nov 9, 2016 at 9:49 AM, Timothe Litt <[email protected]
> <mailto:[email protected]>> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJYI8S5AAoJELWTxzbeFddjwyEP/3jSlKW4XGvgoSL0atslOQRd
ktUClUiOFIuPscOhNVzWVw8eLFBWytI6wLzf9i3rXJt6ylduNuJAYRre5XIZA90P
4qFzzurg5medHwVUi8sSvktXr76aR8p8DUtf4KS1QYrcrYscT/nc5U5ahNTPiKxI
ysaCYNs2R/TdE3uWKVwsjDgnn0Twst8aIDaPIHcF7jqObyp0I7AZsbdH09goNigu
nvKaOCiAEZs+2zrj4JLshBgl1qJ4Hv8to8KTFQZz08xCTzcaSXLO2Bc2OPpEDrDi
4HPGdfoLbER9QbrWK2rhuCW0f2aqiHiEDFNt031p7kwzkHiCoQqoDkz1trMcm23L
pZrcsKTImzmiscAZoxu9RFum4Gc8wXQx5taWzAwiSMR6LnpMt5Wb1cPKz6CjO4Gu
fOF69YLV5wEa1SYBT16EP1ohB6XfN5l+hkI00AJpsyBXM7pzWVGvXKR5XYjJWZSg
QV9E7LxJt8wMPn6DpY2v+YdUPyu0OBxwGBQOna0eJb6HCH2Xk6/T02L9mO6A4oT/
EqlnyIqNZQAc0wx++6fq0zFeusqsmANndtcGD1w8ADL31wNxb3A/o23DB7Kf+nwN
DeIHSvELEqfXbBE/x6RVpEhDz7MyodCpoQcCW6mqbOShGNxK7G06HxwXhbmPskF3
w6JtvSj2Ma7Xg480UcPx
=2yz7
-----END PGP SIGNATURE-----