Description of problem:
We're trying to remove PyXML from Fedora 18 since it's dead upstream and when it's installed the python stdlib overwrites its own xml module with the code from PyXML. That overwriting with old code can cause errors on newer python.
Looking at the code for bkchem and some documentation in the tarball, it looks like the bkchem upstream did some work to remove dependence on PyXML. I found code importing xml.dom.minidom and xml.sax both of which are present in the stdlib.
I also found one plugin that makes use of xml.xpath: bkchem/plugins/gtml.py ("GTML import-export plugin"). xml.xpath is a PyXML extension so this plugin will not work if PyXML is not installed.
* What's the impact if we don't ship this plugin?
* Would upstream be willing to port?
* If we/I port this for upstream, would they be amenable to adding a different library dependency? I have heard that lxml is a good library for adding xpath support to an application (there is no module with xpath support in the stdlib).
Let me play with it. I'm not sure at third, fourth glance. I didn't see any mention of it in the UI, so naturally I dug into the code, and I see the file, but I don't see it called from anywhere. I see gtml references as a dir and in function names, but I don't see anything that calls, imports, or refers to it, except for bkchem/plugins/__init__.py line 23, where a comment references it's removal. So dropping the dep and doing nothing otherwise might be a NOOP.
In the mean time see if you can find any holes in the above.
BTW, by the "it" in the 3rd sentence, I mean the gtml plugin.
And I did a local build without the PyXML dep, installed, and removed PyXML, and I saw no change in behaviour.
Cool. Can we remove the dep on PyXML in the rawhide packages then? I have opened an F19 Feature for removing PyXML so it seems like a good time to do that and make sure no one else reports breakage.