Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Should I list core modules as dependencies?

by vsespb (Hermit)
on Jun 01, 2013 at 21:52 UTC ( #1036507=perlquestion: print w/ replies, xml ) Need Help??
vsespb has asked for the wisdom of the Perl Monks concerning the following question:

Should I list core modules (like: Carp, Exporter, strict, bytes, File::Find, File::Temp) as dependencies, when creating CPAN module?

Some authors don't do it: Test::Deep LWP::UserAgent

Some do: Git-Raw HTML::Builder Also for example Carp module listed as most often required.

And I did not find answer in CPAN::Meta::Spec...

Comment on Should I list core modules as dependencies?
Re: Should I list core modules as dependencies?
by LanX (Canon) on Jun 01, 2013 at 22:04 UTC
    Yes! The corelist can change.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

Re: Should I list core modules as dependencies?
by Old_Gray_Bear (Bishop) on Jun 01, 2013 at 22:44 UTC
    If your module supports older version of Perl, then there may be (probably are!) modules that were not in the Core List at that time.

    At a minimum, I'd include as dependencies all of the modules that were not in the Core List for the earliest Perl version you support. I suspect that the Core List will only grow larger, since removing Modules from the Core would cause breakage, and the P5P tries hard to be backwardly compatible.

    ----
    I Go Back to Sleep, Now.

    OGB

      "I suspect that the Core List will only grow larger"

      Modules are quite often moved out of core. Some of the biggies have been Class::ISA and Switch which were both removed in 5.14.

      CPANPLUS and Module::Pluggable are due to go in 5.20; and CGI and Module::Build will probably go in 5.22.

      Update: removed "probably"; it's now official; they're going.

      package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
Re: Should I list core modules as dependencies?
by ikegami (Pope) on Jun 01, 2013 at 22:59 UTC

    Yes. It'll save you from doing so later if the module is ever becomes slated for removal from core. It's also useful for those analysing dependency trees.

    Modules previously removed from core:

Re: Should I list core modules as dependencies?
by Anonymous Monk on Jun 02, 2013 at 00:05 UTC

    Should I list core modules (like: Carp, Exporter, strict, bytes, File::Find, File::Temp) as dependencies, when creating CPAN module?

    Yes, you should list all dependencies -- its not like you have to pick/choose by hand :) scandeps

      > its not like you have to pick/choose by hand :) scandeps

      CPAN Not found Whatever it was you were looking for, it's not here

      better scandeps.pl

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        better scandeps.pl

        :) cute , I could have sworn at one time it worked without the .pl

Re: Should I list core modules as dependencies?
by tobyink (Abbot) on Jun 02, 2013 at 07:53 UTC

    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

      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

        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
      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.

        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

        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) );
        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) );
        Does that help? Just remember to list dual-lived dependencies. The non-dual-lived modules are already there, just waiting for you:).

      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 :)

        "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
Re: Should I list core modules as dependencies?
by DrHyde (Prior) on Jun 03, 2013 at 10:51 UTC
    Yes, you should. What's in core varies from one version of perl to another. Normally it's just things being added so modern perls have more in core than older ones, but occasionally things get removed. CGI.pm, for example, may be removed soon.

    What's more, you should list every module your code relies on. If your code uses Foo::Bar and Baz::Barf, but Foo::Bar depends on Baz::Barf, you should declare a dependency on both of them, because at some point in the future Foo::Bar might stop depending on Baz::Barf and use something else instead.

    In general, if your code mentions a module, you should list it as a pre-requisite.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1036507]
Approved by Old_Gray_Bear
Front-paged by kcott
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (14)
As of 2014-09-22 15:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (198 votes), past polls