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

[Michael DeHaan]

Michael DeHaan wrote:
> 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 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]
>>   
>
> 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. 
> Agreed.
>
>>  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
>> you.)   
> 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".
>
> --Michael
>
Given no other replies to this commentary, I think we're ok on the 
PyYaml 3000 front (what to do about syck-python is another issue, and 
I'm willing to let it slide if a good working alternative can get out 
there).

I do have people interested in reviewing this (Toshio, you are welcome 
to as well), but I lack a potential sponsor for my first package.   Can 
anyone jump on board and help me out?   The module itself was already 
built with distutils, so the spec only moves it into a more reasonable 
namespace and numbering scheme.

Here's the bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190493

Much appreciated!

--Michael