http://www.perlmonks.org?node_id=1044579


in reply to Understanding CPAN indexing

package
    My::Module;

[download]

is older, and I'm not sure whether all tools support 

meta "no_index"

[download]

I would look at using the older version instead of playing around with the META* files, but that may be because I used CPAN before the META* files came into existence and I am averse to change :).

Personally, I try to keep a version number in all files, and have the version number identical across all files for each release.

Replies are listed 'Best First'.
Re^2: Understanding CPAN indexing
by vsespb (Chaplain) on Jul 16, 2013 at 12:52 UTC
    is older, and I'm not sure whether all tools support
    Which tools involved into this (except PAUSE)? From pause FAQ:
    The PAUSE indexer honours the contents of the no_index and the provides fields.

    Next,

    Personally, I try to keep a version number in all files, and have the version number identical across all files for each release.
    Yes, I saw this in several places. But why exactly? To avoid issue (4) in first post? Or there are other possible issues? Does it make sense for "private" modules?
[reply]

      As I understand it, "provides" beats "no_index". If you want a module to be excluded from CPAN indexes, then you need to make sure it's covered by "no_index" and not included in "provides".

      That said, the main reason you'd normally do that would be for a module that is bundled with your distribution, but not intended for installation. For example, a module that is only needed to run the test suite.

      Modules that are needed for the distribution to run probably ought to be indexed as normal.

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

      If PAUSE honors both, then you should be able to use whatever you like. I haven't followed closely the changes in how the indexer works and what new features the META* files provide.

      I like keeping one version number across a distribution because that makes it really easy to trace back from where a file originated. There is no room for confusion because I never have to remember whether version 0.17 of Foo/Bar.pm had the change that is needed for Foo/Baz.pm v0.38 , and both of them were distributed starting with Foo/App.pm v0.42 in the 0.42 version of the distribution. This is true for me for both "public" and "private" modules, because when trying to track down an error, it's much easier to ask the other end "What is the version number in the file?" than "What version of the distribution did you install?". Often, a module was installed as a prerequisite so the other end does not even remember explicitly installing a module.

[reply]

        Further to that, Perl::Version comes with a very handy script called perl-reversion for bulk reversioning a whole distribution. (Which will handily complain loudly if it notices one of your modules is out of sync.)

        package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
[reply]
[d/l]
        Thanks!
        I probably end up having same version in all modules.
        Immediately after I released "release" CPAN version of my script (previously I had "unzip-and-run" version), one of my users messed up files somehow of old and new version.
        Thus I add version to all files (that solved all of problems in original post, btw), and wrote code like this to check version runtime: 
            for (keys %INC) {
        if (/^App\/MtAws\/(.*)\.pmc?$/) {
            my $module = "App::MtAws::$1";
            my $got = $module->VERSION;
            $got = 'undef' unless defined $got;
            die "FATAL: wrong version of $module, expected $VERSION, f
+ound $got" unless $got eq $VERSION;
        }
    };
}

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom