Re: Declaring optional dependencies

On 09-Nov-16 09:07, David Cantrell wrote:
> I recently broke Catalyst::Devel when I uploaded a dodgy version of
> Devel::CheckOS. Personally I don't like Catalyst and consider this to
> have been a service to humanity, but I understand that some people
> differ on this :-)
>
> Thing is, my code doesn't show up as a dependency in CPANdeps. Turns
> out that it's because it's a dependency of MooseX::Daemonize, which is
> in turn an *optional* dependency of Cataylst::Devel. MooseX::Daemonize
> doesn't show up in the META.{yml,json} files, and so CPANdeps doesn't
> spot it. Instead it's in Makefile.PL thus:
>
>   if (!$Module::Install::AUTHOR && $^O ne 'MSWin32') {
>     requires 'MooseX::Daemonize'; # Optional in scripts
>     requires 'Starman'; # Optional in scripts
>   }
>
> Seeing that we've gone down the route of having eleventy different
> *_requires for build-time requirements, test requirements, and so on,
> I think it makes sense to also put optional dependencies like this in
> META.*. Any comments?
>
Anything optional seems to be a swamp.

I have a module that has 'recommended' modules - but if they're present,
they have a minimum version.
I can't specify in META that I have three optional dependencies, but at
least one is required for sensible operation.  The solution seems to be
marking the dependency list 'dynamic' - e.g. meaningless.  Then the
Makefile.PL will have to update the dependency array.  (I use
Dist::Zilla to package.)  I haven't implemented it in my package yet,
but JSON::MaybeXS seems to have similar (slightly simpler) Makefile.PL
logic.

cpan and cpanm seem to handle 'recommended' differently.  IIRC, neither
defaults to installing 'recommended' modules.

If there's energy to address the case of grandchild optional
dependencies, it would be nice if all the issues related to optional
modules were addressed - including in the install UIs.

The goal ought to be that one can express "I want Foo:: in functional
condition", and that it installs and tests with one command - at least
by default.  The problem is expressing 'in functional condition' in some
way that covers all the strange stuff that authors come up with.  At
first glance, that seems like an expression language that can probe the
environment, e.g.

    i_require ( Foo v0.99 || Bar v 68 )  && ( Nil v11 && IPv6 active ||
-e /dev/smartcard ) && (installed Nix::? Nix v11  && Devel::CheckOS)...

Or something like that....

Then there's what the right semantics are for 'suggests'... and
'recommends' -- which I gather have been debated before, with no
coherent resolution.

All of which is why I think you're stepping into a swamp :-)

But not one that's environmentally sensitive in the usual sense.  Just
messy, and deep.

Sigh.

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

iQIcBAEBAgAGBQJYIzdpAAoJELWTxzbeFddjHRwP/i7TJw6vz2I85IjHlbFIR2ET
03Q7DRBdgGizwP26BMeogl3sKAMSDcv6fE4SQJ6d8h4T7BgDlchdQB+J5IUaEheP
gP16LEQcraXJPUUKF3ZdUsO04RouSW5pOKJszMV0qFQp07M1EfNX3eXfJGz4WZ5C
NXhx/5cj4eYFyFC5qiURZG//Pkg1CON/p4x5qWnf2/NsQOKIcvXcaYzJnqucGNAE
DNKX/QM6v2l92S91VtqdcusMidbjfWVoKL1tOPQtDuiGKVIehqb928eTOfNCveSj
b0gcITfwruc8Uw0Us8AEeerHqjy7mSkN3TN0nQIrJFz0Lu28OpJZpechMZPtwumS
4nWdtpEm8NXuGFVevrzt9HdzZRWg5HcgvTHtR1Bye7FDU4q62CBq+kKnOYyavz+1
u35q1yu+2Q1tAIN/o1XXdNd2SA1QcsmvfWUq73LCswdHVvJ9OcnUaTgxU9PvT7jH
D0tD5j97X+IwWQMuvQwx4Ysi4kUV/z/kiYHh55Hy8iDpU3g/CM+F29vOuRAh4VdJ
KcG+7cB6OoQ0BmNWg1VSjZi8aoFsG47AifVh5sA3IxhnflQw7VX2Xw868DF3II9I
NNKskH78Lb+yWmlAcPtDgLY51hOsDdr+ZCvR0+h1qJBk56mndno3K0yHJhPWBikI
JUc6wyPcCXDQhm55Z95C
=RdZx
-----END PGP SIGNATURE-----