in reply to Should I list core modules as dependencies?

Personally I do not usually list core dependencies.

Modules can be removed from core, which will technically break your distribution if you haven't listed them as dependencies. However, for people who have problems installing your distribution, the fix is simple (and quite obvious given the error messages they are likely to see) - they just need to install the dependency first, and then install your distribution.

Besides which, the deprecation cycle for core modules is quite long. If, after releasing Perl 5.20, p5p decide to drop module Foo, then Perl 5.22 (released a whole year after 5.20) will need to include a version of Foo that issues deprecation warnings, and 5.24 (released a year later again) will be the first version without Foo.

So if you pay attention to what modules are being discussed, you'll get maybe 2 years' notice about module removals. Plenty of time to push out an updated release listing an extra dependency. (And if you don't have the tuits to upload a small bugfix update in 2 years, you should probably think about taking on a co-maintainer.)

Even if you pay no attention to what's going on in p5p, you'll start seeing lots of test failures from CPAN smoke testers on the Perl 5.23 development releases many months before the Perl 5.24 release date.

There are some modules that seem unlikely to be removed in the foreseeable future - strict, warnings, constant, overload, Carp, Exporter, Scalar::Util and Test::More for example.

So why don't I list them? Seeing a long list of dependencies can put some people off using a module. Type-Tiny says Dependencies: none, just as a "::Tiny" module should. :-)

However, Type-Tiny does list a "test_requires" dependency on Test::More 0.96 in META.yml. Why? Because I need 0.96 or above. Perl 5.8.1 (the oldest Perl supported by Type-Tiny) ships with Test::More 0.47. The first Perl to ship with Test::More 0.96 in core was Perl 5.13.4. So that's a reason to list particular core modules as dependencies - you need a newer version than what was bundled with some of your supported versions of Perl.

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
  • Comment on Re: Should I list core modules as dependencies?

Replies are listed 'Best First'.
Re^2: Should I list core modules as dependencies?
by LanX (Saint) on Jun 02, 2013 at 08:49 UTC
[reply]

      Most of those were only in core very briefly during development runs. attrs was the only one that had ever appeared in a stable release, and it had been deprecated for a very long time. (It was removed in Perl 5.11.0, but had been deprecated in Perl 5.6, around a decade earlier.)

      package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
[reply]
[d/l]
        I agree with you that pragmas are a very reliable dependency.

        But (for groups of humans) simple rules are usually better!

        Encouraging a "my module has less dependencies then your module" race is dangerous in my eyes, as long as it's based on interpretations of such fuzzy definitions

        Don't you think it would be better, if everybody was listing every used module / pragma, and CPAN and/or MetaCPAN or whatever provides an objective metric (a number) or graph?¹

        Edit:

        At the very least active core modules could be automatically filtered of such a tool.

        The dependency tree at CPAN already marks core dependencies, maybe this has just to be graphically enhanced.

        Update

        Practical suggestion:

        Here a dependency tree of Moose linked from CPAN.

        Hiding non-deprecated core-dependencies by default and adding a button Show core modules shouldn't be too difficult.

        (BTW: Plz note that Moose lists warnings but not strict ;)

        Cheers Rolf

        ( addicted to the Perl Programming Language)

        ¹)<meditation> Possibly based on:

        • deprecation
        • age in Core
        • age in CPAN
        • last update
        • open bugs
        </meditation>
[reply]
[d/l]
[select]
Re^2: Should I list core modules as dependencies?
by vsespb (Chaplain) on Jun 02, 2013 at 07:59 UTC

    Thanks! Yes, technicaly module dropped from core is not a problem. If I suspect, that module will be dropped, I can list it.

    But modules like 'strict', 'Carp' unlikely will be dropped soon.

    So I was wondering if I _must_ list all modules

    But this topic shows, that some people list all modules, some no. And there is no single standard for it

[reply]
Re^2: Should I list core modules as dependencies? (yaml comments)
by Anonymous Monk on Jun 02, 2013 at 10:29 UTC

    So why don't I list them? Seeing a long list of dependencies can put some people off using a module.

    Well, it appears you use META.yml, and since yml supports comments, you can ... corelist ... make clear which dependencies are CORE and which are not

    But I suppose that might still put people off :)

[reply]
[reply]

        no need for yaml comments

        Sure there is, people read META.yml you know

[reply]

      "yml supports comments"

      And I'm sure they're very useful for people handwriting their META.yml files. For the rest of us who generate them using CPAN::Meta (e.g. via ExtUtils::MakeMaker) YAML comments are not really an option.

      package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
[reply]

        And I'm sure they're very useful for people handwriting their META.yml files. For the rest of us who generate them using CPAN::Meta (e.g. via ExtUtils::MakeMaker) YAML comments are not really an option.

        Oh yeah, its not like there exist people who can write programs :)

[reply]
Re^2: Should I list core modules as dependencies?
by vsespb (Chaplain) on Jun 02, 2013 at 09:36 UTC
    So why don't I list them? Seeing a long list of dependencies can put some people off using a module.
    Yes, that's primary reason why I care about dependencies.

    None of CPAN tools can clearly show that module use just a few non-Core dependencies, and instead shows long-long tail of core modules and testing modules.
[reply]

      If you look a little deeper at the long-tail of core modules, you'll see that most of the core modules listed are dual-lived. Those are the core modules that are costantly being updated and can be downloaded from CPAN. I usually avoid listing non-dual-lived modules because they will cause CPAN to try to install perl again, which isn't what you or the user really want. For example, if you try to install bytes---CPAN will install bytes but also all of the core all over again.

      Let's look at the list you gave. I left out the non-dual-lived modules: 
      #!/usr/bin/perl

use strict;
use warnings;
use CPAN;

CPAN::Shell->install(qw(
    Carp
    Exporter
    File:Temp)
);

      [download]
      Adding the dependencies for Test::Deep: 
      #!/usr/bin/perl

use strict;
use warnings;
use CPAN;

CPAN::Shell->install(qw(
    Exporter
    Carp
    File::Temp
    Test::NoWarnings
    Test::Tester
    ExtUtils::MakeMaker
    Test::More
    List::Util)
);

      [download]
      Does that help? Just remember to list dual-lived dependencies. The non-dual-lived modules are already there, just waiting for you:).
[reply]
[d/l]
[select]
        I usually avoid listing non-dual-lived modules because they will cause CPAN to try to install perl again, which isn't what you or the user really want. For example, if you try to install bytes---CPAN will install bytes but also all of the core all over again.
        So, Git::Raw and HTML::Builder (see links in original post) are trying to install new Perl ? I doubt.

        Why it should? For example 'strict' module version specified as 0, that means it's installed, and should not be updated...
[reply]

      So why don't I list them? Seeing a long list of dependencies can put some people off using a module. Yes, that's primary reason why I care about dependencies. None of CPAN tools can clearly show that module use just a few non-Core dependencies, and instead shows long-long tail of core modules and testing modules.

      Funny :) I don't remember seeing any wishlist items bug reports about someone wanting non-core dependencies hilighted

      corelist can tell you if something is core, so all you have to do is filter whatever through corelist

      OTOH, scandeps doesnt list core modules by default

[reply]
        I don't remember seeing any wishlist items bug reports about someone wanting non-core dependencies hilighted
        Why report wishlist of you can just edit your makefile/build.pl ?
        OTOH, scandeps doesnt list core modules by default
        I tested, it claims it does not, but it does (it reported base, Carp, Encode, List::Util for me) However seems it doesnt list non-dual-life modules.
[reply]

In Section Seekers of Perl Wisdom