Bug 844072 - Get rid of the dep on PyXML
Get rid of the dep on PyXML
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: subscription-manager (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adrian Likins
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 843176
  Show dependency treegraph
 
Reported: 2012-07-28 11:36 EDT by Toshio Ernie Kuratomi
Modified: 2013-01-11 14:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-11 14:47:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Toshio Ernie Kuratomi 2012-07-28 11:36:05 EDT
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 12:15:20 EDT
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 09:01:00 EDT
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 13:59:00 EDT
commit 0bebe4cdfe39700a420f4db821c2c4f61f2d6829
Author: Adrian Likins <alikins@redhat.com>
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 14:47:20 EST
Looks good to me.  Closing this Rawhide.

Note You need to log in before you can comment on or make changes to this bug.