It is my opinion that (most) optional prereqs should at least be listed in
the 'suggests' category of prereqs, to at least allow for static inspection
tools (such as CPANdeps) can be aware of a potential relationship.
Regarding Timothe's observations that optional prereqs are a swamp -- yes,
but less so than you think -- the semantics for spelling out optional deps
is well-established. Code runs in Makefile.PL (or Build.PL) at configure
time that determines the final prereq list based on the installation
environment, and this data is used to build MYMETA.json. When
dynamic_config => 1, *this must be done* to determine the prereq list --
the list in the shipped META.json need not bear *any* relationship to the
final prereq list (although politeness and convention dictates that
META.json should at least contain a proper subset of the final prereq list).
For Dist::Zilla-based dists, dynamic prereqs can be declared in Makefile.PL
using Dist::Zilla::Plugin::DynamicPrereqs. This plugin has evolved through
use in several complicated distributions, but there's certainly room for
more development :) But you should be able to insert any custom
Makefile.PL code you need using this plugin. Please let me know via RT,
github or irc if there's anything more I can add that would help!
On Wed, Nov 9, 2016 at 6:49 AM, Timothe Litt <tlhack...@cpan.org> wrote:
> 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.
>
>
>
