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