Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > perl.module-authors > #3322 > unrolled thread
| Started by | david@cantrell.org.uk (David Cantrell) |
|---|---|
| First post | 2016-11-09 14:07 +0000 |
| Last post | 2016-11-09 09:49 -0500 |
| Articles | 2 — 2 participants |
Back to article view | Back to perl.module-authors
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
| From | david@cantrell.org.uk (David Cantrell) |
|---|---|
| Date | 2016-11-09 14:07 +0000 |
| Subject | Declaring 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]
| From | tlhackque@cpan.org (Timothe Litt) |
|---|---|
| Date | 2016-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