Red Hat Bugzilla – Bug 190493
Review Request: python-yaml
Last modified: 2007-11-30 17:11:31 EST
Spec URL: http://people.redhat.com/misa/rpms/python-yaml/python-yaml.spec
SRPM URL: http://people.redhat.com/misa/rpms/python-yaml/python-yaml-0.3000.20060502-1.src.rpm
Description: python-yaml is a packaging of Python YAML 3000, a YAML library for Python. I'm adding this because syck-python in Extras (or upstream syck, for that matter) doesn't have a dump() function (no serialization, so it's only half of a library) and this parser is more fully featured. It is also YAML 1.1 compliant as opposed to syck which only partially complies with YAML 1.0, and has some robustness issues in the C codebase. It's also a pure python module, which is also a plus for something as simple as YAML. dump() and load() have been manually tested and work, plus there is a suite of unit tests that have also been tested.
I should also add that this is my first package for FC Extras, so I'm seeking a
I'd appreciate it if anyone with sponsorship abilities could help me out!
For what it's worth, Jeff Johnson has mentioned here that he has already
packaged PySyck, which could also be an option for getting Python to have a
decent YAML library that works. We could package both, or just PySyck. Doesn't
matter much to me.
Details are in comments here:
One issue from the author of PyYaml 3000 today was that it does YAML 1.1, but
not 1.0 ... for interoperability this may point to PySyck making a bit more
sense for cases where multiple languages want to get at the YAML data (interop
with Ruby until it has a 1.1 parser, for instance). Personally I am interested
in mainly using Yaml to store state in single applications so this doesn't
concern me a whole lot, but it could affect other folks quite a bit -- and I'd
like to make sure that use case is covered. (Especially Python/Ruby
So, if there is a bugzilla on including PySyck, I'd just assume get behind that
one if it's easier. A working YAML implementation is better than none at all,
and per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189281 we currently
don't have a working option.
For reasons of interop, I'm suggesting we terminate this 'zilla item, and
instead move forward with resolving the core issue:
The preferable way I see of doing that is by fixing the bug below by packing
PySyck and orphaning the obsolete syck-python. Aside from s/yaml/syck on the
import, it's a drop-in replacement.
FYI, if anyone is watching this: PyYAML officially released today, and there is
now a RbYAML parser for YAML 1.1 as well
Here's the yaml-core post from the author:
PyYAML: YAML parser and emitter for Python
YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and
emitter for Python.
PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages. PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.
PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.
You may download PyYAML from http://pyyaml.org/wiki/PyYAML.
Seems like we have interop issues vs upstream involvement. If whytheluckystiff
isn't interested in making timely releases that address the deficiencies for
non-ruby bindings that makes pysyck a lot less attractive. As you note, yaml
1.1 implementations are popping up (the ruby version is even based on pyyaml...)
Are we doing python programmers a favor by implementing a yaml-1.0 parser as
the only option so they have to make an incompatible update to yaml-1.1 later?
There's a place for both yaml 1.0 and 1.1 libraries right now but if I'm
developing a new python app with yaml support, I think pyyaml's involved
upstream and Unicode support make it a better candidate. Up to you if you want
to be in charge of the pyyaml package or want to work on pysyck (and from there
we'll figure out if Oliver is still interested in syck or if it needs to be
orphaned and somes else take over.)
I'm currently experiencing some issues with the Fedora Accounts system that no
one is answering, and there has been no interest in sponsorship, so for now, I'm
going to let this die.
However these RPM's are packaged if anyone wants to steer them through. They
were only minimally tweaked from Upstream to change the name.