Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Understanding CPAN indexing

by vsespb (Chaplain)
on Jul 16, 2013 at 12:31 UTC ( #1044576=perlquestion: print w/replies, xml ) Need Help??
vsespb has asked for the wisdom of the Perl Monks concerning the following question:

I have modules in my distributing, that I don't want to provide to end users. Actually I don't want to provide anything, except, probably, main module (App::MtAws), to end users, as my distribution is not a library, but a program, i.e. it is not for linking with other code.

The only thing should be available for end user is one script to be ran from command line, and some .pod in the future.

Examples of modules, I don't want to "provide" are: App::MtAws::Filter App::MtAws::GlacierRequest (total over 40).

here is the distribution

I have several issues with this.

1) I don't understand what different levels of "providing" a module exist. It seems that I don't want modules to be listed on CPAN pages, don't want it to appear in search, but I do want to "preserve" that namespace.

2) I have "no_index namespace" in my meta (both json and yml) (I've tried no_index directory also):

"no_index" : { "namespace" : [ "App::MtAws" ] },

but it seems it doesn't work, because I see in my meta the following:

"provides" : { "App::MtAws" : { "file" : "lib/App/", "version" : "0.972" }, "App::MtAws::CheckLocalHashCommand" : { "file" : "lib/App/MtAws/" }, ...

3) Seems unneeded modules appear on metacpan pages but not on CPAN pages

4) When I upload new, non-dev version to PAUSE, I am getting the following email shortly:

Status of this distro: Decreasing version number ================================================ The following packages (grouped by status) have been found in the dist +ro: Status: Decreasing version number ================================= module: App::MtAws::CheckLocalHashCommand version: undef in file: lib/App/MtAws/ status: Not indexed because lib/App/MtAws/CheckLocalHashComm in V/VS/VSESPB/App-MtAws-0.962.tar.gz has a higher versio +n number (0) module: App::MtAws::ChildWorker version: undef in file: lib/App/MtAws/ status: Not indexed because lib/App/MtAws/ in V/VS/VSESPB/App-MtAws-0.962.tar.gz has a higher version number (0)

I believe this is because I previously used M:B version, which reported "version=0" for packages without version: example

and now I use M:B which reports no version in this case: example

Question is how to fix those emails and what else this issue affects in practice (except sending warning over email)?

5) I there a difference (in theory and practice) between

package # hide from pause mymodule

meta "no_index"

Replies are listed 'Best First'.
Re: Understanding CPAN indexing
by Corion (Pope) on Jul 16, 2013 at 12:39 UTC
    package My::Module;

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

    meta "no_index"

    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.

      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.


      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?

        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/ had the change that is needed for Foo/ v0.38 , and both of them were distributed starting with Foo/ 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.

        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
Re: Understanding CPAN indexing
by DrHyde (Prior) on Jul 17, 2013 at 10:27 UTC
    Use fatpack in your 'make dist' to pack all the modules into a single executable.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1044576]
Approved by marto
Front-paged by kcott
and a log crumbles through the grate...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2018-04-25 17:35 GMT
Find Nodes?
    Voting Booth?