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

[Toshio Kuratomi]

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 at 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....)

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060502/d07d0f10/attachment.sig>