in reply to Re: Should I list core modules as dependencies?
in thread Should I list core modules as dependencies?

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.
  • Comment on Re^2: Should I list core modules as dependencies?

Replies are listed 'Best First'.
Re^3: Should I list core modules as dependencies?
by Khen1950fx (Canon) on Jun 02, 2013 at 10:30 UTC

    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]
Re^3: Should I list core modules as dependencies?
by Anonymous Monk on Jun 02, 2013 at 10:24 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.

    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]

        Why report wishlist of you can just edit your makefile/build.pl ?

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

        You said , these things don't have this feature I want, so I prefer to see make incomplete Makefile.PL/Build.PL

        How is editing Makefile.PL/Build.PL so it becomes incomplete, preferable to improving "CPAN tools to clearly show that module use just a few non-Core dependencies"?

        So instead of fixing one or two or three tools , to ease fears of dependencies, you prefer incomplete Build.PL/Makefile.PL?

        incredible

[reply]

In Section Seekers of Perl Wisdom