The original findpacs() was returning either [Package]
or ([Package], [str]) depending on the `fatal` option.
This confused pylint and it was returning false-positives:
E1101: Instance of 'list' has no '...' member (no-member)
Old xml.etree.cElementTree versions (python2) reorder the attributes
while recent xml.etree.cElementTree versions (python3) keep the
document order.
Example:
python3:
>>> ET.tostring(ET.fromstring('<foo y="foo" x="bar"/>'))
b'<foo y="foo" x="bar" />'
>>>
python2:
>>> ET.tostring(ET.fromstring('<foo y="foo" x="bar"/>'))
'<foo x="bar" y="foo" />'
>>>
So far, the testsuite compared two serialized XML documents via a simple
string comparison. For instance via,
self.assertEqual(actual_serialized_xml, expected_serialized_xml) where
the expected_serialized_xml is, for instance, a hardcoded str. Obviously,
this would only work for python2 or python3.
In order to support both python versions, we first parse both XML
documents and then compare the corresponding trees (this is OK because
we do not care about comments etc.).
A related issue is the way how the testsuite compares data that is "send"
to the API. So far, this was a plain bytes comparison. Again, this won't
work in case of XML documents (see above). Moreover, we have currently
no notion to "indicate" that the transmitted data is an XML document.
As a workaround, we keep the plain bytes comparison and in case it fails,
we try an xml comparison (see above) as a last resort. Strictly speaking,
this is "wrong" (there might be cases (in the future) where we want to
ensure that the transmitted XML data is bit identical to a fixture file)
but a reasonable comprise for now.
Fixes: #751 ("[python3.8] Testsuite fails")
For now, we assume that if the "exp" keyword argument is specified,
then it is a str. In this case, we simply encode it (using the utf-8
encoding).
Also, simplify the code a bit (get rid of the if-statement that is
always executed).
Importing `cElementTree` has been deprecated since Python 3.3 -
importing `ElementTree` automatically uses the fastest
implementation available - and is finally removed in Python 3.9.
Importing cElementTree directly (not as part of xml) is an even
older relic, it's for Ye Time Before ElementTree Was Added To
Python and it was instead an external module...which was before
Python 2.5.
We still need to work with Python 2.7 for now, so we use a try/
except to handle both 2.7 and 3.9 cases. Also, let's not repeat
this import 12 times in one file for some reason.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The files are now opened as rb for diffing. In python2 nothing changes.
In python3 the returned diff is bytes now.
The following changes were made:
* commandline.py: The returned diff is now bytes
* get_diff now returs the diff as a bytes-like object
* run_pager writes with sys.stdout.buffer.write if message
is not a string
* for the commit message the returned diff needs to be decoded
now. Otherwise it will just producce garbage. For the commit
message the diff on decoded bytes-objects is ok. (nothing harmfull
can happen here)
* fixed submit_action_diff
* fixed request_interactive_review
With this change you get bytes with python3 and string in python2
disable travis tests for python 3.x until the full python3 branch
is merged. Otherwise the tests will fail and master isn't python3
ready anyways
This functions are used in the whole code and are
mandatory for the python3 support to work. In python2
case nothing is touched.
* cmp_to_key:
converts a cmp= into a key= function
* decode_list:
decodes each element of a list. This is needed if
we have a mixed list with strings and bytes.
* decode_it:
Takes the input and checks if it is not a string.
Then it uses chardet to get the encoding.
This is needed for a new validation of the source server.
The source server will 'ask' for the sha256 sum of files which are new or
modified and osc calculates the sha256 sums for those files and sends them
back to the server.
The server checks the sha256 sums and if dies if something is wrong.
There is no need to compute the request creator, because it is
stored in the request xml. Moreover, the old computation yields
a wrong result (see issue #286).
