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