* new function create_text_meter with fallback selection
* NoPBTextMeter.start() will print the basename (if not stated otherise with
basename = None)
* The callers that should use an alternare TextMeter class now call create_text_meter()
* The callers that should not use and alternate TextMeter (because of different handling,
like build.py) call create_text_meter(use_pb_fallback=False)
* the warning 'Please install the progressbar module' is now only shown once
improvements
Now, CpioWrite provides a bytes-only API. It would be also possible
that the API accepts bytes and str (we would need to explicitly
encode the latter) but this would be a bit inconsistent wrt.
cpio.CpioRead (which is bytes-only).
Also, by using a bytesarray instead of a [] we avoid several
intermediate ''.join(...)s.
This is a bytes only API because a filename in a cpio archive can
contain, for instance, illegal utf-8 sequences. A user can decode
the filename/content as she wishes.
A ValueError is more appropriate because there is no issue with the
ar archive itself. Also, the old codepath never worked because the
fn parameter was missing.
Since an ar archive can contain arbitary filenames (that is a
filename can be an invalid utf-8 encoding (for instance,
"foo\xff\xffbar")), the ar module provides a bytes only API. A
user can decode filenames as she wishes.
Note: if a "fn" parameter is passed to Ar.__init__ it should be a
bytes (a str is also ok, but then be aware that an ArError's file
attribute might be a str or a bytes).
There is no need to unpack a single byte because it is not
affected by (byte) endianness (and that's what struct.unpack is
about). Moreover, rpmquery.unpack_string now supports an optional
encoding parameter, which could be used by the python3 port to
decode a string. Note: in general we cannot assume that all strings
in a rpm are utf-8 encoded (it is possible to build a rpm that
contains illegal utf-8 sequences).
Unbreak "osc build" output in case of a missing progressbar module (this
slipped in in commit 8a6abe3a6c ("warn user
if python-progressbar is not installed")). This change has some
"disadvantages":
- a print in fetch.py, which is always executed in in case of a missing
progressbar (an external user might just import the verify_* functions)
- an explicit print in get_binary_file, which is actually the task of
*some* progress_obj
For an alternative "fix", see [1]. Anyway, merged...
[1] https://github.com/openSUSE/osc/pull/502#issuecomment-453165987
With the NoPBTextMeter class the build view gets broken.
Old view:
1/11 (repo) filename
new view:
Please install the progressbar module...
Please install the progressbar module...
Please install the progressbar module...
With this commit the old behavior is restored.
The getbinaries call now lists the file he downloads instead of just
stating "Please install the progressbar module..." several times.
(but only if not called with the option quiet)
Since commit 8a6abe3a6c ("warn user
if python-progressbar is not installed") it is always safe to import
the meter module (even if the progressbar module is not installed).
On ImportError have_pb_module is false and the class NoPBTextMeter gets
returned which prints "Please install progressbar module..." on TextMeter.start()
Use io.BytesIO in the tests.common module (preparation for python3).
For now, the python3 travis runs got disabled as well (will be enabled,
once the python3 migration is done).
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.
