Ratings and Reviews for CPAN


Rate a distribution

Find a distribution you would like to review:

Recent reviews (RSS feed)

DBIx-Class (0.082840) *****

DBI Porn

RT-Extension-ConditionalCustomFields (0.02) *****

Very useful

Git-Raw (0.73) *****

I have used Git::Raw when implementing a backend for Git::Database. While doing this, I only used a very limited subset of the library, somewhat "close to the machine". Therefore, this review does not reflect the state of the whole library interface, only the limited subset that I needed.

I found the interface with many similar but different classes (Git::Raw::Object, Git::Raw::Odb::Object, the various Git::Raw::{Commit,Blob,Tree,Tag}, etc) a little cumbersome. The documentation is terse, but nicely complemented by the libgit2 documentation, so I never really needed it.

The support for libgit2 is not complete, but the current maintainer (JACQUESG) is a joy to work with: he was so very responsive, that my requests for features were usually implemented within the day. An unsupported libgit2 function is not a defect: it's an opportunity to see him at work.

Net-Graphite (0.17) *****

Easy to use and works well.

I use this module to send snort IDS stats into Graphite: github.com/gregvolk/snort2graphite

Chart-Plot (0.11) ****

Pretty good for what it says. Get's the job done, even the last update were in 2000s, it still worked pretty good. I'm looking at taking over this module/distro or hoping anybody else with math/plotting skills/knowledge taking over this module. I don't have to use Python matplotlib for plotting scatter graph anymore. :)

CryptX (0.044)

Works well and actively maintained.

MIME-Type-FileName (1.0)

The module is very simple and minimal. It consists of a small piece of code which is run when the module is used, which maps a hash of file endings to mime types, a routine called "guess" which strips the file extension and returns the equivalent mime type, or "application/octet-stream" if no extension is found, and a big block of data of extension to file name.

Unfortunately it overwrites its own values, so .jpeg turns into image/pjpeg, as reported here:


The provenance of the list of mime types is also unknown, the author doesn't mention where it comes from, but there are some definitely wrong ones like "application/x-javascript" which should be "application/javascript". The IANI list is online and available in text form for anyone to copy here:


so that kind of issue shouldn't have arised.

I wonder why the author created this module. I remember using MIME::Types back in 2008 or so, and the first version of this one dates from 2012. Good old MIME::Types gets 13/16 file names to correct mime types in my test, but this only gets 8/16. What was the original motivation for making another file extension to mime type module? It's not documented.

Anyway it is nice and simple, and self-contained, but unfortunately not very accurate.

For a comparison with similar modules, please see my page at www.lemoda.net/perl/find-type-of-file/

MIME-Detect (0.08)

MIME::Detect offers two ways to get the MIME type. One is "mime_types", which gets the mime type from the file itself, similar to File::MMagic or File::Type. The other is "mime_types_from_name", which looks at the extension part of the file name, like ".txt" or ".png". Both of these functions return a list of mime types in case more than one pattern matches.

MIME::Detect uses a very large XML file from freedesktop.org for the matching patterns.

In the tests I tried, MIME::Detect performed fairly well, although the "mime_types" method couldn't detect some formats. The failures included executable files, files containing old encodings, and the old Microsoft BMP image format.

MIME::Detect was last updated in 2016 and seems to work well on most file types, so it seems this can be recommended for modern people.

Unfortunately though, it is by far the slowest of all the modules I tried. Loading and using this single module actually takes much more time than loading and checking the types of the files with all the other modules, "File::MMagic", "File::MMagic::XS", "Media::Type::Simple", "MIME::Types", "File::LibMagic", and "File::MimeInfo", combined.

Here is the time of my test with all the lines related to MIME::Detect commented out, but with all of the other above modules:

real 0m0.495s
user 0m0.440s
sys 0m0.056s

Here is the time after MIME::Detect is uncommented:

real 0m1.918s
user 0m1.768s
sys 0m0.150s

A bit slow! I have not profiled to find out what causes this slowness, but it's probably because the module parses a two megabyte XML file each time it is started.

It would make sense to preprocess the huge XML file, and distribute the preprocessed version, rather than parse the huge XML file each time the module is used. The bulk of the XML file is actually comments describing what the mime types are in various languages.

Regarding the documentation, the list of all the other modules for detecting mime types in the module's SEE ALSO is useful.

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

MIME-Types (2.13)

It seems to work well enough. The results are almost, but not quite, identical to File::MimeInfo. For example an Excel file gets this:

File::MimeInfo: application/vnd.ms-excel
MIME::Types: application/vnd.ms-excel

but a bmp file gets this:

File::MimeInfo: image/bmp
MIME::Types: image/x-bmp

Unlike Media::Type::Simple it has enough sense to return an undefined value when it sees an extension it doesn't recognise, rather than throw a fatal error. Unlike File::MimeInfo, it doesn't try to open the file and guess what is inside it, which may be better in some circumstances.

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

File-MMagic (1.30)

All the reviews are very negative, but the module is self-contained and works well as far as it goes, which is in identifying file formats which were common ten years ago. It has more successes at identifying files than File::Type in my tests.

The formats it recognises are dated though, it doesn't recognise modern executable formats, XML, SVG, can't really distinguish when there are non-ASCII bytes in the file, but it does a better job than File::Type in several cases.

But it seems nearly abandoned judging from the bug reports. Perhaps this module is ripe for adoption.

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

File-MimeInfo (0.28) *****

If you want to go from file extension to mime type, this module does the job well, and additionally if it cannot work out what the mime type is from the file extension, it tries to read a bit of the file and work out from that whether it's binary or text.

A rival for this module is Media::Type::Simple, but that module is inconvenient in that you have to strip out the file extension yourself, and for some reason Media::Type::Simple throws a fatal error when given a file extension it doesn't recognise.

Although the results of the two modules are mostly identical, File::MimeInfo seems to give marginally better mime types for some kinds of data.

Anyway, this module seems useable to me.

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

Media-Type-Simple (v0.31.0)

Since there doesn't seem to be a "Media::Type" or even a "Media::Type::Complicated" or "Media::Type::Difficult" the naming of the module is somewhat suspect.

The module itself is very unpretentious, only mapping from file extensions to mime types and back.

So far so good, but for some insane reason it dies if you send it an extension it doesn't recognize, rather than just returning the undefined value:

eval {
my $media_type = type_from_ext ('kangaroo');
if ($@) {
print "Died like this: $@";

$ perl mts.pl
Died like this: Unknown extension: kangaroo at mts.pl line 8.

Why does it die like that? That means I have to wrap every single use of this in an eval in case some file or another which I'm trying to find the type of has some unknown extension - essentially I have to test the file extension before I give it to this, or something equally ridiculous.

If you are writing code which is meant to tell the user what type something has, throwing a fatal error when the user sends you something of unknown type is not a sane practice. That is like inviting people to ask you questions, and then pulling out a gun and shooting someone if they ask you a question you don't know the answer to. Just say "I don't know", and return the undefined value!

As far as the results go, on various types of file it gives more or less identical results to File::MimeInfo, with a few exceptions. For example ".bmp" got me "image/x-ms-bmp" with this but "image/bmp" with File::MimeInfo, and .gz got me "application/x-gzip" from this, but "application/gzip" from MIME::Types and File::MimeInfo.

The fatal errors from unknown extensions part is stupid, but apart from that it seems to work well enough.

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

File-Type (0.22)

This one more or less works for the basic cases, as long as you only need file types that were common up to 2004. Some interesting failures were that it labelled an Excel file (old format) as an msword file, a pure ASCII file as "application/octet-stream", and it seems to like adding "x-" in front of things, so you get "image/x-png" for png images, or "image/x-bmp" for bmp images. Interesting successes were that, unlike File::MMagic, it managed to spot non-ASCII bytes in a text file, and it managed to distinguish an executable from a stream of binary data. It has no idea about XML or SVG and puts anything remotely Unicode into "application/octet-stream".

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

File-Type-WebImages (1.01)

If you already know that the file is an image file, and you want to find out whether it is a PNG, BMP, GIF, or JPEG, this can do that job for you. Other than that it returns undefined for everything, including SVG, which it doesn't handle.

But if you already know that you have image data, you probably already know the format as well, and as it mentions in its own documentation, any of the other modules on CPAN can tell you the mime type, so I can't see what use this is.

For a full comparison including source code and results on various files, see www.lemoda.net/perl/find-type-of-file/

File-MMagic-XS (0.09008)

It's called File::MMagic::XS but it is not compatible with File::MMagic, you have to use ":compat" to get the same interface, and even then it doesn't return the same results as File::MMagic, so it might as well have been released under a different name.

I thought it did a reasonable job on the files I tried it with. Where it differs from File::MMagic, it guesses better than File::MMagic does, and File::MMagic guesses better than File::Type.

For a full comparison of the mime type modules on CPAN, see www.lemoda.net/perl/find-type-of-file/

File-LibMagic (1.15) *****

Of the modules on CPAN which attempt to guess mime types by reading the file, rather than from looking at the extension, File::LibMagic seems to be the best one both in terms of speed and accuracy.

Unfortunately, the underlying library cannot properly detect encodings, and falsely claims UTF-8 to be "binary".

The solution I eventually settled on for my job was a combination of "read_binary" from File::Slurper, "valid_utf8" from Unicode::UTF8 to validate the encoding, and "info_from_string" from this module used on the text read in by "read_binary". I decided to use File::LibMagic rather than MIME::Detect because MIME::Detect is extremely slow to load and operate, and the encoding problems this has could be worked around using the above methodology.

For a full comparison including source code, see www.lemoda.net/perl/find-type-of-file

Alien-wxWidgets (0.67)

Currently I cannot install the CPAN module Alien::WxWidgets<br>
When I run "cpan force install Alien::wxWidgets", the operation fails, stating that it can't connect to sourceforge.net. <br>

Error message stated:

Fetching wxWidgets...
fetching from: prdownloads.sourceforge.net/wxwindows...
Fetch failed! HTTP response: 500 Internal Server Error 500 Can't connect to svwh.dl.sourceforge.net:443 at inc/My/Build/Base.pm line 306.
Fetch failed! HTTP response: 599 Internal Exception at inc/My/Build/Base.pm line 306. Could not open socket to 'prdownloads.sourceforge.net',

'No connection could be made because the target machine actively refused it.' at inc/My/Build/Base.pm line 306.
Unable to fetch archive at inc/My/Build/Base.pm line 307<br>
Can someone help me out? I badly need to install the CPAN modules Alien::WxWidgets, and Wx, so that I can then install Padre. Alien::WxWidgets, and Wx, are Padre dependencies.

AI-MXNet (0.03)

good project for perl and AI

Text-Unidecode (1.30) ****

Great... AFTER you figure out that you need to be first dealing with UNICODE not UTF-8.

It does work... but you need to be sure you are using it correctly for your application. Here is a simple example.

use Encode qw/encode decode/;
use Text::Unidecode;
$data = decode("UTF-8", $data);
$data = unidecode( $data );

Finance-Robinhood (0.17) *****

this is the api i'm looking for a long time,just add simple script and make the trade automatically.

Text-Unaccent (1.08)

As you can see from these test results:


this has had an unpatched bug report for ten years or so where it doesn't cope with sixty-four bit systems:


It's regrettable that people are using this as a dependence even now:


Another thing worth noting is that this module completely ignores Perl's Unicode encoding. Try commenting out the "use utf8;" in the following:

use utf8;

use Text::Unaccent;

my $charset = 'UTF-8';

my $string = 'ÀÁÂÃÄÅAあ';

print unac_string($charset, $string);

The output results will be identical.

BSD-Sysctl (0.11) *

Doesn't work on NetBSD.

Mac-Pasteboard (0.008) *****

Thank you - great DWIM experience.

File-Find-Wanted (1.00) ****

File::Find lacks the "making easy things easy" part, so modules like this are great. A further step would be an option to omit $wanted for even simpler cases, but that would probably break the interface. Another alternative is File::Finder, but it forces OO style.

Paws (0.31) *****

An ambitious project, with clean results so far.
Instance roles just work. Sane internal representations. Great stuff.