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:

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.

> strict, warnings, constant, overload,

have any pragmas ever been removed?

update

ah pre-coffee, never mind =)

• assertions
• assertions::activate
• assertions::compat
• attrs
• legacy

Cheers Rolf

( addicted to the Perl Programming Language)

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

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

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

> ... make clear which dependencies are CORE and which are not

no need for yaml comments

The perl version number is used to filter test results and also to determine what's a core module and what's not -

Cheers Rolf

( addicted to the Perl Programming Language)

update

added quote

"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

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.

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

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

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

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

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.