Re: [MathDOM] Re: Packaging MathDOM, patching lxml
Brought to you by:
scoder
From: Stefan B. <beh...@gk...> - 2005-11-04 19:14:29
|
Stefan Behnel wrote: > Jeff Kowalczyk wrote: >> The other option is to include a private copy of the full lxml source and >> apply your patch in place, then have setup.py build and install that in >> a private subdir. If the runtime test for a patched lxml in the default >> python path fails, have the import statement import the private copy. > > With the modified setup.py, you can easily ship lxml with MathDOM. The test > for a patched version also has an option. But lxml is not yet included in > the build process. Once it *is* built, all you have to do is copy the > resulting lxml directory (containing the files etree.so, _elementpath.py > and __init__.py) into the mathml directory. Since the only module that > depends on lxml is mathml.lmathdom, Python will simply look there first and > find the correct version. The tests and examples will *not* find the > patched version, but they are not of interest to an installation anyway. > >> lxml is becoming a core product, even Zope has considered making it a >> dependency. I don't think it will be practical to apply post-release >> patching to lxml in anything but experimental setups or package-private >> copies. > > Ok, sounds reasonable. So maybe it would help to integrate the build > processes of lxml and MathDOM. In that case I'd prefer shipping only the > generated C-code for lxml, i.e. lxml/etree.c, to strip the additional Pyrex > dependency (the latest official Pyrex version is still broken when used > with GCC4, so that is really the right thing to do). I'll have to look into > that. Now that I looked into it, I do no longer think a package private copy of lxml is a good choice. Lxml is part of the API of the mathml.lmathdom module, so existing code will import it directly, i.e. break if it is moved. Multiple installed copies will really confuse users and make its usage difficult. So I finally think that installing the patched version independently is the best choice. I'll keep bugging the lxml maintainer to get my patches in there. Stefan |