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@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]
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
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
