CPAN Ratings

Ratings and Reviews for CPAN

Rate a distribution

Find a distribution you would like to review:

Recent reviews (RSS feed)

Path-Tiny (0.104) *****

Path::Tiny is truly awesome. The API has everything you need, and it's just so *easy* to use.

We use it extensively to replace all the file reading/writing, copying/moving, directory traversal code; it makes the code simpler and more robust - what's not to like?

Net-Gnutella (0.1)

Completely undocumented module, it does not even have so much as an abstract. Since the release of version 0.1 was in 2001, this seems to be abandoned.

Math-Expression (1.47)

It's very difficult to make head or tail of what this module is supposed to do from reading the documentation. The example code is not formatted correctly as pod, and I tried typing in various bits of the documentation to no avail.

Paws (0.32) *****

Incredible project. If you are into Perl and you use AWS you *NEED* this.

Tree-Simple-View (0.19) *****

Thanks for tweaking it for HTML5 :)

Dist-Zilla (6.009) ****

dzil is a very valuable tool if you have to maintain a significant number of CPAN or darkPAN distributions. Plugins allow to easily improve the quality of your packaging or to increase testing. Plugin bundles allow to standardize your packaging process across multiple projects, and this is very helpful as a CPAN author or in a company.

The IRC support (#dzil on is highly responsive and will help you to find a solution to any problem you may encounter.

Unfortunately support for perl < 5.14 has been suddently dropped with dzil 6.0, so I'm stuck with dzil 5.047 (from BackPAN) for a perl 5.10.1 only project until someone implements cross-perl testing.

Data-Uniqid (0.12) *****

This module creates a unique id by printing a base 62 version of the time and the process number, and the hostname if you want a globally unique ID.

I've been using this to generate about 300 IDs a day on a public-facing web service for about six years. I have not had any problems with it. I require IDs which are unique to my pages only, not globally unique.

Data-UUID (1.221) **

Over the years, many people have recommended and used this module. The module's maintainer applies patches supplied by the community and releases upgrades without regressions.

However, much its code exists as XS, not perl, and the community has not provided fixes for reported bugs, including a security vulnerability reported in 2013 as CVE-2013-4184.

As of 2017, I would avoid using this insecure module and choose something else, such as UUID::Tiny, instead.

Algorithm-Dependency (1.110) ***

Happily returns result when graph is cyclic (and thus proper topological sorting cannot be done). See also Data::Graph::Util for a simpler alternative.

Data-Match (0.06) **

(Reviewing Sort::Topological, which is included in Data-Match distribution at the time of this review).

Hangs when given a dependency like: a => ["a"]. Happily returns result when graph is cyclic (and thus proper topological sorting cannot be done). See also Data::Graph::Util for alternative.

Encoding-FixLatin (1.04) *****

Well documented simple module that does exactly what I needed. Highly recommend it.

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:

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 initialisation routine which maps file endings to mime types, a routine called "guess" which guesses the mime type, and extension to file name data.

A bug in the initialisation routine means it overwrites its own values, so .jpeg turns into image/pjpeg. I reported it here:

The list of mime types contains some 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:

I'm not sure why the author created this module. MIME::Types was already mature when this module was first released in 2012. In my test, MIME::Types gets 13/16 file names to mime types correct, but MIME::Type::FileName gets only 8/16 right.

MIME::Type::FileName is simple and self-contained, but not very accurate.

For a comparison with similar modules, see

MIME-Detect (0.08)

MIME::Detect offers two ways to get the MIME type, "mime_types", which gets the mime type of a file by reading the file itself, and "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 for the matching patterns.

In my tests, MIME::Detect performed fairly well, although the file-inspecting "mime_types" method couldn't detect some formats, including executable files, files containing old encodings, and the old Microsoft BMP image format.

MIME::Detect is by far the slowest of all the modules I tried. Loading and using this single module takes 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.

The time of my test with with all of the above modules except MIME::Detect:

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

The time of my test including MIME::Detect:

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

It's probably because the module parses a two megabyte XML file each time it is started.

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

For a full comparison including the testing program and results on various files, see :

MIME-Types (2.13)

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

File::MimeInfo: application/
MIME::Types: application/

but a bmp file gets this:

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

Unlike Media::Type::Simple it returns 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.

For a full comparison including source code and results on various files, see

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. In my tests, it had more successes at identifying files than File::Type.

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

But it seems abandoned, judging from the bug reports:

For a full comparison including source code and results on various files, see

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

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 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
Died like this: Unknown extension: kangaroo at line 8.

That means one has to wrap every single use in an eval in case some file or another has some unknown extension. Throwing a fatal error when the user sends something of unknown type is not a good 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!

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.

For a full comparison including source code and results on various files, see

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

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