PyXML package - deprecate it?
Roman Rakus
rrakus at redhat.com
Thu Feb 23 16:19:01 UTC 2012
On 02/23/2012 04:54 PM, Toshio Kuratomi wrote:
> On Tue, Feb 21, 2012 at 06:48:11PM +0100, Roman Rakus wrote:
>> Hi all,
>> looks like PyXML package is deprecated since python itself provides
>> xml mechanisms.
>> When you look deeper,
>> python's xml provides:
>> "dom", "parsers", "sax", "etree"
>> and PyXML provides:
>> 'dom', 'marshal', 'parsers', 'sax', 'schema', 'utils', 'xpath', 'xslt'
>>
>> So, PyXML duplicates dom, parsers and sax (and looks like python's is
>> in better shape). Is any package using marshall, schema or any other
>> not in python itself?
>>
>> Deprecate PyXML or just remove duplicated parts?
>>
> It's not as simple as saying that a library provides something that has the
> same names as modules in the stdlib, you also have to figure out
> compatibility and whether removing it will cause any problems for software
> that Fedora ships.
>
> Looking at the sourceforge page, the authors of PyXML are heavily involved
> in python core development so it's likely that they worked to merge the
> useful bits of PyXML into the stdlib before they abandoned it:
> http://sourceforge.net/projects/pyxml/
>
> However, it also looks like PyXML is a collection of works that the
> sourceforge authors didn't necessarily originate. With that in mind, they
> may not have been able to get permission of the various original authors to
> merge a particular module into the python stdlib. However, there may exist
> independent upstream versions of those modules that would be better to ship
> than shipping PyXML in those cases.
>
> The best way to proceed is likely similar to how I looked at whether it
> would be okay to retire python-sqlite2: Take all the packages that depend on
> PyXML and grep through their sources to find where they use the PyXML
> modules (rpm -ql PyXML shows that everything in PyXML is in an "_xmlplus"
> python package so you'll see things like "import _xmlplus.dom" and "from
> _xmlplus import dom". grepping for _xmlplus will probably work). In some
> cass, you'll likely find this was an old dep and the source no longer uses
> it. Others may be conditionalized:
>
> try:
> from xml import sax
> except ImportError:
> from _xmlplus import sax
Look at stdlib xml - it tries to import _xmlplus. And it will replace
stdlib with nonstd. It's kind of "what?". I can try to report bug on it.
>
> Testing these packages to know that they behave properly is good but at
> least you can be confident that the upstream code is intended to work with
> the stdlib modules instead of the PyXML modules.
>
> If you find any code that's using _xmlplus unconditionally, you'll have to
> write patches to use the stdlib or separate modules. Then test your changes
> and send the patches upstream. Given the upstream note that PyXML is
> deprecated and the authors do not intend for people to use it, this category
> would hopefully be very small. But you won't know until you look.
>
> -Toshio
>
>
Currently I'm going through packages and using pylint on *.py files on
%preped sources. And using --deprecated-modules option of pylint. I will
post results, report bugs and so on...
Anyway, you're right that better is to ask upstream how different are
stdlib and _xmlplus.
RR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120223/5fd9b4f7/attachment.html>
More information about the devel
mailing list