[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: syck-python / request to orphan / wanting to replace with pyyaml.org's YAML stuff

Toshio Kuratomi wrote:
On Tue, 2006-05-02 at 14:30 -0400, Michael DeHaan wrote:
Bugzilla 189281 references the YAML parser for Python in FC-extras as being broken. The bug report went to oliver linux-kernel at on 4/18 and I've emailed him on 4/28 inquiring about the 4/18 bug report and volunteering to help. No replies yet on either account, I'm assuming long vacations and such are possible, such things are understandable and ok.

That bug doesn't show that it's broken, just poorly designed :-)  (I'm
not arguing that syck's python bindings aren't broken in other ways and
deserve to get replaced....)


Not having a YAML package for Fedora that can serialize anything is pretty broken, IMHO :)

The Python community has apparently seen that the syck bindings that ship with syck (current=0.55) are broken, so they've come up with a version of syck-python that is 0.61 (http://pyyaml.org) on their own . They are also working on a Python Yaml 3000 replacement library, that is apparently also a good candidate.

My suggestion is that syck-python be orphaned due to the fact that (1) it's broken since it can't serialize anything at all (no dump function), and (2) syck isn't incredibly robust. Given this, I'm planning on packaging a "python-yaml" for extras using the Python-YAML 3000 or Python-Syck codebase here, which has syck at 0.61. We can then pull python-syck out of the repository. Yes, I'm signing up to do this, assuming we can orphan the broken package to reduce confusion.

I liked the idea of yaml but have refrained from using it due to the
problems with the python-syck bindings. I think it would be valuable to
have working bindings whether or not syck-python is orphaned.

 Here are
some questions:

pysyck:  the pyyaml.org website provides a patched syck that is an svn
snapshot plus pyyaml patches.  Is an unpatched syck going to have
significant deficiencies?
Yes. An unpatched syck doesn't have a working dump function, which makes it at least 50% broken, so I'd call those dependencies rather major. I have not researched their other fixes to syck. The one issue with packaging their pyyaml patched version now is the 1.1 compliance. We have to move to 1.1 at some point, and it looks to me that the 3000 version is good enough now. (See below on syck issues).

Is upstream syck going to make new releases
or is all development of the library concentrated in the ruby tree?  Has
the pysyck community proposed their changes to upstream syck?
I've contacted whytheluckystiff (upstream) about his thoughts and relationship with pysyck. He is for all intents and purposes in the Ruby camp, and I'm not sure how much time (if any) is spent on the Python ones. The python brokeness has no doubt been reported at least once, which makes me believe upstream syck isn't the answer. Further, per a coworker of mine (I haven't followed up on this myself), syck's source doesn't do a good job of checking memory allocation calls, does some reallocs, and so forth ... so I am well inclined to use a non-native parser for stability/safety reasons. PyYaml 3000 would fit this niche nicely.

pyyaml3000: No released tarballs.  Does upstream have a timeline for
that or are we going to be making snapshots for quite a while?
As for pyyaml3000, I have a RPM on my desktop now (already built) and am about to submit it to FC-extras for review. It seems very stable and I can contact them about plans on releasing snapshots. For now, I've built a tarball myself.

To me, making a pyyaml3000 package (with some idea of what we can expect
from upstream) could go the route of any other Extras package.  (After
all, we have both libxml2 with python bindings and elementTree already.)

pysyck could be treated the same way but seems like it would benefit
from coordination with the syck maintainer (to Obsolete syck-python and
stop building that as a subpackage, is upstream syck going to make
python fixes, should we add pysyck patches to our syck library, etc)
See if Oliver responds to inquiries about you packaging pysyck (or if he
doesn't have time for syck anymore and is willing to hand it off to
I've contacted whytheluckystiff to see his opinions on upstream pysyck's brokenness as well, just for good measure. I agree with you that having duplicate implementations won't hurt (if both work), but I do think that having just one broken implementation in there (syck-python) is not enough. So whether we orphan the broken syck-python or not, I'm backing the yaml 3000 as the right way to go. Package is currently named 'python-yaml', since we don't have one, and I don't want version numbers in the formal package name. Version is "0.3000.20060502".


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]