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

[Michael DeHaan]

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