Bug 844072

Summary: Get rid of the dep on PyXML
Product: [Fedora] Fedora Reporter: Toshio Ernie Kuratomi <a.badger>
Component: subscription-managerAssignee: Adrian Likins <alikins>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: alikins, bkearney, dgoodwin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-11 19:47:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 843176    

Description Toshio Ernie Kuratomi 2012-07-28 15:36:05 UTC 
Description of problem:
For Fedora 18 we're trying to get rid of PyXML due to a cobination of it being dead upstream for many years and that when it's installed, the python stdlib overwrites its own xml module with PyXML.  This combination leads to errors because PyXML's code is older and contains bugs that have been fixed in the stdlib.

I've taken a look at why subscription-manager has a dependency on PyXML and it looks like it is due to one usage of the xml module for parsing dates:

./test/test_managerlib.py:import xml
./src/subscription_manager/managerlib.py:import xml.utils.iso8601

Can this functionality be ported to another library?  Perhaps one of the ones on this page: http://wiki.python.org/moin/WorkingWithTime
Comment 1 Toshio Ernie Kuratomi 2012-07-28 16:15:20 UTC 
If I understand what the code in managerlib.parseDate() is doing (and I might not!) I think it could be replaced with one call to dateutils.parser.parse(date).  dateutils handles both timezones and overflow itself (The behaviour on 32 bit systems with overflow is different, though.  The test case ends up with parsed.year == 9999, parsed.month = 9, parsed.day = 6 on both 32 bit and 64 bit systems with dateutils while with xml.utils.iso8601 the date overflows and is set to the default value.)
Comment 2 Devan Goodwin 2012-07-31 13:01:00 UTC 
I've been asking around, I believe this was done as it was the only working date formatter on EL5. We're going to try to address it in our next sprint so within the next few weeks.
Comment 3 Adrian Likins 2012-10-09 17:59:00 UTC 
commit 0bebe4cdfe39700a420f4db821c2c4f61f2d6829
Author: Adrian Likins <alikins>
Date:   Mon Oct 8 14:14:31 2012 -0400

    844072: remove use and dep of PyXML
    
    PyXML is deprecated in Fedora, so remove it.
    Only use of pyxml was for it's iso8601 date parsing,
    so replace it's usage with dateutil (and require
    that now).
    
    dateutil.parser.parse() behaviour is slightly different,
    especially for year 2038 issues. Dateutil handles this
    better at least till year 9999, so update test cases
    for those cases.
    
    Note: previous parseDate was actually incorrect for cases
    where the server returned iso8601 dates with a tz (instead
    of UTC). This doesn't seem to matter because the server
    always returns iso8601 dates with UTC tz. Updated
    test cases for this scenario.
Comment 4 Toshio Ernie Kuratomi 2013-01-11 19:47:20 UTC 
Looks good to me.  Closing this Rawhide.