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@xxxxxxxxxxxxxxx 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....) [snip] > 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? 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? pyyaml3000: No released tarballs. Does upstream have a timeline for that or are we going to be making snapshots for quite a while? 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 you.) -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
