Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > perl.module-authors > #3322 > unrolled thread

Declaring optional dependencies

Started bydavid@cantrell.org.uk (David Cantrell)
First post2016-11-09 14:07 +0000
Last post2016-11-09 09:49 -0500
Articles 2 — 2 participants

Back to article view | Back to perl.module-authors


Contents

  Declaring optional dependencies david@cantrell.org.uk (David Cantrell) - 2016-11-09 14:07 +0000
    Re: Declaring optional dependencies tlhackque@cpan.org (Timothe Litt) - 2016-11-09 09:49 -0500

#3322 — Declaring optional dependencies

Fromdavid@cantrell.org.uk (David Cantrell)
Date2016-11-09 14:07 +0000
SubjectDeclaring optional dependencies
Message-ID<58232D9D.2030406@cantrell.org.uk>
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?

-- 
David Cantrell | Minister for Arbitrary Justice

There are two kinds of security, the one that keeps your sister
out, the one that keeps the government out and the one that
keeps Bruce Schneier out.

[toc] | [next] | [standalone]


#3323

Fromtlhackque@cpan.org (Timothe Litt)
Date2016-11-09 09:49 -0500
Message-ID<0e950d48-7f56-9f64-8d25-3161ed8bc0bb@cpan.org>
In reply to#3322

[Multipart message — attachments visible in raw view] — view raw

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.


[toc] | [prev] | [standalone]


Back to top | Article view | perl.module-authors


csiph-web