Check if Perl module exists on Cpan - cpan

I have a long list of Perl modules. I know some of them, but most not. I need to know which of them are available on Cpan. I know, i can copy and paste each item of the list into the cpan.org, but i want to learn a bit more about Perl and do this with a perl script.
I know that:
cpan -D ModName
will tell me which version is localy installed, and which is the latest on Cpan. Is there another way to get this info?

You can check this tutorial by Gabor Szabo. Not exactly related, but by using MetaCPAN::API->module($module_name); while looping on an array of your #modules_names, you could build a report of which module is available or not on CPAN. Not tested, but I wonder that if the module is not available, it will return undef.
Note that on the documentation of MetaCpan::API, it's author considers the module as deprecated and recommend the use of MetaCPAN::Client.

With smonff's tips I found Module::CheckVersion
which exactly does what I want, THX.

Related

Simplest way to get a comprehensive listing of package names available in CPAN?

Suppose that, as a private project, I have implemented a Perl package, and tested it, both formally and through extensive everyday use. I find the package useful and solid enough to warrant submitting it to CPAN.
Up to this point, since the package has been a private project, I have not worried too much about the package's name, but now that I want to submitted to CPAN, however, I would like the package's name to fit well within the ecology of package names already in CPAN.
In order to find a suitable "CPAN name" for my package, I would have to inspect a comprehensive listing of all these package names1.
What is the simplest way to get this comprehensive listing of names of packages in CPAN?
ObPedantry
(IOW, if the question above is already clear enough for you, you may safely ignore what follows.)
I don't think that I can give a technically correct formal definition of what I mean here by "package name", so let me at least give an "operational definition".
If, for example, the one-liner
$ perl -MFoo::Bar::Baz -c -e 1
fails with an error beginning with
Can't locate Foo/Bar/Baz.pm in #INC ...
..., but after installing some distributions from CPAN, the same oneliner succeeds with
-e syntax OK
...then I'll say that "Foo::Bar::Baz is a package name in CPAN".
(We could split hairs over the package/module distinction, and consider scenarios in which the distinction matters, but please let's not.)
Furthermore, if after inspecting the list this question asks about I discover that, on the one hand, there are in fact many eminent package names in CPAN that begin with the prefix Foo::Bar::, and on the other, there are none (or negligibly few) that begin with the prefix Fubar::, then this would be a good enough reason for me to change the name of my Fubar::Frobozz package to Foo::Bar::Frobozz before submitting it to CPAN.
1 Of course, after inspecting such a list, I may discover that my package does not add sufficiently new functionality relative to what's already available in CPAN to warrant submitting my package to CPAN after all.
If you have run cpan before, you have downloaded a comprehensive package and distribution list under <cpan-home>/sources/modules/02packages.details.txt.gz.
A fresh copy is available on any CPAN mirror, e.g.
http://www.cpan.org/modules/02packages.details.txt.gz .
PAUSE::Packages can do what you want, however you probably want to use this list, but http://prepan.org/ can provide advice/review before submission to cpan, with of course reading on the naming of modules first.
Are you sure that's a thing you want? There are 33,623 distributions on CPAN at the time of writing. Within cpan you can enter
cpan> d /./
That's d for distributions followed by a regex pattern that matches the names you're interested in
If you're really interested in packages -- and a distribution may contain multiple package names -- you need
cpan> m/./
where m is for modules. There are 163,136 of those, which means there's an average of four or five packages per distribution, and it takes cpan a few minutes to generate the list. (I'm sorry, I didn't monitor the exact time.)
You could use MetaCPAN::Client
I found this article which gives the idea about using this module.
#!/usr/bin/perl
use strict; use warnings; use MetaCPAN::Client;
my $mcpan = MetaCPAN::Client->new();
my $release_results = $mcpan->release({ status => 'latest' } );
while ( my $release = $release_results->next ) {
printf "%s v%s\n", $release->distribution, $release->version;
}
Currently this gave me 32601 result like this:
Proc-tored v0.11
Locale-Utils-PlaceholderBabelFish v0.004
Perinci-To-Doc v0.83
Mojolicious-Plugin-Qooxdoo v0.905
App-cdnget v0.05
Baal-Parser v0.01
Acme-DoOrDie v0.001
Net-Shadowsocks v0.9.0
MetaCPAN-Client v2.006000
This modules also gives information about release, module, author, and file & uses Elasticsearch.
It also get updated regularly on every MetaCPAN API change.

Why is the same module listed three times at metacpan.org?

Searching for Devel::Peek at metacpan.org gives the following screen shot:
Why is the module listed three times? (It looks a little bit strange, and could easily confuse the user..)
Oddly enough, there's one missing. The following are Devel::Peek's official distributions:
perl
Devel-Peek
These two distributions are returned when searching search.cpan.org, and the only two distributions returned when searching search.cpan.org.
Being part of the perl distribution and part of its own distribution is called being a "dual-lifed" module. It allows the module to be bundled with Perl without having to upgrade Perl to upgrade the module.
I don't know why meta::cpan doesn't pick up the official distribution, and I don't know why it doesn't flag the other distributions as unofficial. You could alert the site's maintainers of the problem.
Conversely, I don't know why search.cpan.org doesn't return CookBookA and CookBookB, and why it doesn't flag theses other distributions as unofficial when one goes to it directly. I think it has to do with the fact that Devel::Peek is only present as a documentation file (.pod) —not a module (.pm)— in them.

How to determine the package for a specific perl module?

Is there a way to determine the package for a specific perl module?
I'm currently looking for XML::Code...
And, to narrow down the possible answers: I don't want to use cpan.
Thanks in advance!
You mean Debian package? Why not just search your repository for "XML::Code"? The following will usually give the answer, though.
Find the name of the distribution for the module by searching for the module on CPAN. In this case, it's XML-Code.
Convert it to lowercase.
Perpend lib.
Append -perl.
So, libxml-code-perl.

How to guess minimum perl version a particular script is written for?

I have a bunch of scripts that I wrote at times when I did not realize how use v1.2.3; can be useful. So some of them may be using features from later versions of perl, some of them may be OK with, say, perl 5.8.
Now I would like to get that into some order and add proper uses where there is need for them, just to be able to sleep better. :-)
How should I do that? Is there any tool that could help me make an educated guess?
Perl::MinimumVersion
Find a minimum required version of perl for Perl code
The most reliable way is 1) to write a decent test suite, then 2) to run your tests using each version of Perl.
You've surely already done the first part (!), and the second part is actually pretty easy to do using perlbrew.

How can I list all CPAN modules depending on a given module?

How can I list all CPAN modules depending on a given module? For example, create a list of modules using Class::Workflow?
There's two valid questions about dependencies:
What modules does the given module require?
The reversed question: Which modules depend on the given module?
For the former, the authoritative but non-recursive answer is usually to look at the META.yml file that's part of most modern distributions. If there is no such file, you may try looking at the Makefile.PL or Build.PL build tools that ship with it. If you want to know all dependencies and not just the direct ones, cf. ghostdog74's answer. Specifically, David Cantrell's 'CPANDeps' is very, very handy.
Obviously, the latter question is impossible to answer by inspecting the module itself. If you don't want to grep an unpacked minicpan, the best solution is something like the "used by" section of a module's CPANTS entry.
you can use a module such as CPAN::Dependency, or try this online , among many others.
I’ve found CPAN::Dependency and CPAN::FindDependencies on CPAN, they might help you.
Some other options:
Module::ScanDeps
Perl::PrereqScanner