To erikb495: the tarball of this version (and subsequent devel versions) unpacks correctly for me, as well as for metacpan and search.cpan.org ( metacpan.org/source/INGY/YAML-1.23 ), this is not a problem in the module. Please use the issue tracker or a module's listed support channels to discuss issues rather than a review site.
This YAML won't install. It unpacks in the current directory in a flat hierarchy.
ns2 .../home/bennett/tmp 554# ll YAML-1.23.tar.gz
-rwxr-xr-x 1 bennett tsysadm 83566 Aug 19 09:20 YAML-1.23.tar.gz*
ns2 .../home/bennett/tmp 555# tar tzf YAML-1.23.tar.gz
... you get the idea ...
I think a distinction needs to be drawn between the Perl only module and the other implementations. Other reviews except Dan's fail to make this distinction. The Perl module fails to implement the YAML language correctly, and is painfully slow. YAML::XS implements it correctly and is far faster (our testing suggests ~300x faster on simple tests).
As such I see no reason to use the Perl YAML, and our decision out of ignorance to do so will now cost us time and effort to correct as we need to identify files written using Perl YAML, read them with Perl YAML and write them with YAML::XS. The documentation currently suggests avoiding the Perl version but it could perhaps be more strongly worded.
YAML has worked very well for me on a variety of projects, but most especially the small ones. IMHO, there is no easier interface. In one case I used YAML to create (and recreate from a database) very large glossaries that are loaded with Catalyst as a memory-resident database (which is fabulously fast now). (We still use multiple YAML files on our Catalyst servers instead of the new Catalyst preference.)
In reply to Dan Dascalescu: you seem to be spamming CPAN Ratings. While I agree on some of your ratings, most are biased. It's usually a "best practice" to use the pure perl version as the default fall back. You can try the ::XS first, but it won't hurt to have a compatibility layer, if you are not configuring all the machines that the code runs.
And I don't think anyone cares if Catalyst used this or that. YAML is not part of Catalyst.
This module is a total success in my eyes. I use it everwhere. Way better than Config::* at configuration, and way better than Dumper, or JSON at simple serializing. If you need a simple method of serialization, that doesn't require Storable speed, use YAML! If you need a simple configuration file: use YAML! If you need to replace Dumper with something that isn't so ugly and doesn't suck, use XXX.pm.
Great module. And, the negative reviewers, come on... If you don't want the more sophisticated nested structures... don't use them. Compare how they look in other markups and you'll come back to the conclusion YAML is the only way to go.
I just wanted to echo Adamâ€™s sentiments here. Letâ€™s put it this way: the YAML spec is a good deal more complex than XML 1.0. â€™nuff said.
In addition, 0.58 depends on Test::Base, which in turn depends on Spiffy, which in turn makes me really uncomfortable.
Someone should take the most important 10% of YAMLâ€™s syntax and make a spec out of that. It would be brilliant.
(Update: Now that I am, temporarily, the maintainer for this is CLEARLY deserves a better score)
Yet Another Markup Language (YAML) was a great markup language. A way to handle scalars, array, hashes and multi-lines in a human-readable form, and move to and from data structures easily, theoretically in many languages (I have no experienced in this regard).
The best comment I ever heard was "It's great, we just spit out our nightly processing run reports in YAML and the bosses secretary can read them just fine".
Except that somewhere along the way, it would seem the dream was lost. Instead of a straight forward documents<--->struct language, we are seemingly now left with a multi-doc-per-file data serialization language with all sorts of nasty holes in it.
In attempting to become all things to all people, it has become a failure at all of them (except possibly as a debugging data dumper).
It fails as a simple markup language, as it now supports structures and notations that humans have trouble understanding, especially non-technical humans.
It fails as a data serialization language. You simply can't serialize all the oddities of Perl data structures, such as circulars and objects and overloads and so on, without extensive work, and the assistance of those classes.
Storable does these tricky bits right, but it's taken years. Adding support for Singletons to Storable alone took several months, involved 4 people, and produced what is probably the largest rt.cpan.org comment trail of all time (Bug #4901)
YAML just blindly blesses things into classes, regardless of whether the class can support that, is loaded, or even exists.
You cannot implement Perl-complixity serialization without class hooks, and you can't sanely implement class hooks in any sort of cross-language fashion.
Noting the 4 outstanding bugs rated "Critical", 12 rated "Important", and about 15 other smaller ones, and as much as it pains me to do this, I have to rate YAML as a failure.
And given the mission it has now set itself, I cannot see it ever being able to succeed. There are too many irresolvable paradoxs.
I'd greatly like to see something that addressed the original goal... perhaps "YIML - YIML isa Markup Language"?
Sorry, I can't share the euphoria.
I try and retry YAML once a year. I'm really willing to give it a
chance but I'm still unsuccessful.
YAML calls itself a data serialization language. And that's exactly
what I can't do without fear. For years now.
In the early days it misinterpreted hash keys and values in subtle,
hard to expose ways (leading zeros, version numbers and excessive
newline/carriage-return usage). Ok, with >= 0.37 the hard times of
ForceBlock seem to be gone, fine.
Now I fight with segmentation faults when my strings contain strange
characters (I can't reduce it to minimalistic data examples, sorry,
maybe I report my examples anyway, the longevity of unresolved bugs
on rt.cpan.org kept me away so far).
I don't want to think about the "right" content of my data when I use
something called "data serialization language". I like the good warm
feeling when using Perl for handling my data, and this feeling went
away every time I tried YAML.
In my understanding the root for the problems is the own data parsing
although using Perls parser (via eval) eventually would be more
robust. (Yes, I read about the advantages of not using Perl's eval.)
Don't get me wrong, I respect the idea, the YAML format itself and the
implementation, too. I just had problems with it since my first
try. More than with other CPAN modules.
Forgive me if I'm the only unlucky yaml fellow.
YAML is extremely nice or, to use author's words, really cool. It is much more legible than awkward XML and matches Perl way of life, without being bound to Perl only.
The module is really useful and gives us the immediate benefit of using YAML today. It has many problems and the version 0.50 is expected with anxiety. The interface is simple and obviously easy to use. Sometimes one misses it is not more powerful, for instance, LoadFile does not accept globs (which is a pity). I find that the two utility scripts C<ysh> and C<xyx> are handy tools.
I think YAML has a very promising role in Perl developments and other languages. One would not regret to experiment with YAML 0.35 today and even use it for production purposes. But we sure long for YAML 0.50 which probably will come with support to YAML specification 1.0 (not yet finished).
Simple yet powerful.
I use it for configuration files, as a serializer, for test definitions and as a drop in replacement for Data::Dumper.
Has a few problems while dumping some data structures through (but it is able to dump data structures containing Apache::Request objects (where Data::Dumper fails)).
Anyway, YAML is one of the modules I install first on any new system :)
Overall a very useful module, both for debugging complex data structures and for serializing data, such as configuration options.
I use YAML everywhere I used to use Data::Dumper. Its format is more compact and easier to read than Data::Dumper's. It is also more secure, as you reload the data using a function, and not 'do'. I also tend to use it for configuration files, over XML::Simple: it's more compact, easier to use (no complex configuration options) and to read.
I still can't write a YAML file, but I find it very easy to edit.
Lastly, I found INGY pretty responsive to change suggestions.
2 hidden unhelpful reviews