-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Python 3.4, 3.5 and 3.6 #168
Conversation
In Python3 dicts don't have an iteritems method, we use six.iteritems instead. In Python3 dict's values() and keys() methods don't return lists, we have to cast them explicitly.
six.string_types is basestring in Py2 and str in Py3
The package is called ConfigParser on Py2 and configparser on Py3
On py3 Popen.communicate returns bytes for standard streams. This commit turns on textmode (universal_newlines=True) to return a string on Py2 and Py3.
On Py3 this would return bytes otherwise.
Also updates the pip installs to upgrade packages if necessary.
Travis can't find a python 3.5 binary. This commit configures pyenv in the before_install section so that tox can find 3.5.
Tox "factors" provide better ways of configure conditional dependencies and commands for different tox environments, than named testenv sections. This commit merges the unittest and the pylint/bandit testenv sections back into one default testenv section and manages conditional deps/commands using factors. Additionally, the commit adds Python versions 3.4, 3.5 and 3.6
Modifies .travis.yml to run tox for each TOXENV with the corresponding Python version. Before, we started all tox builds with the same Python version and had tox/pyenv create the test virtualenv with the respective Python version, which threw pyenv errors.
Use max Python version supported by both bandit and pylint for lint environment. For the unittest environments py{VERSION}-unittest tox automatically selects the desired VERSION. The commit also adds a comment about how to run an individual tox environment.
Pylint and bandit flag different things in different Python versions, hence it's a good idea to run them in every tox Python test environment. This commit removes the sophisticated testenv case handling with tox factors from previous commits and makes each Python test environment run first pylint, then badit and eventually the unittests.
In newer Python versions using log.warn makes pylint complain about deprecation.
Exclude version dependent imports from code coverage for coverage consistency across versions.
df255c0
to
0a4bff5
Compare
1 similar comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually surprised how many little changes we had to do.
@@ -146,7 +146,7 @@ def compute_keyid(pubkey_packet_data): | |||
hasher.update(b'\x99') | |||
hasher.update(struct.pack(">H", len(pubkey_packet_data))) | |||
hasher.update(bytes(pubkey_packet_data)) | |||
return binascii.hexlify(hasher.finalize()) | |||
return binascii.hexlify(hasher.finalize()).decode("ascii") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if for all of these instances we want an errors='ignore'
or some sort of error handling...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think just blowing up is better. What we could do is to catch exceptions and re-raise with a redacted error message. Maybe worth a note in #126.
|
||
stdout_str = stdout_file.read() | ||
stderr_str = stderr_file.read() | ||
stdout_str, stderr_str = process.communicate() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we had opted to not do this due to performance concerns/buffering. Is this still the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I timed the function call for ls -Rl /
and it executed without error in about 4 minutes, returning a stdout string of about 170MB.
>>> import timeit
>>> timeit.Timer("in_toto.runlib.execute_link(['ls', '-Rl', '/'], True)", setup="import in_toto.runlib").timeit(1)
247.98906087875366
The timed ls -Rl
in bash takes longer probably due to writing the ouput to the terminal.
$ time ls -Rl /
real 4m57.299s
user 0m51.453s
sys 2m20.026s
I think it's fine for now. Also it is only a temporary solution, if we decide to adapt #160
Let me know if you think it is good to merge. |
Fixes issue #:
Closes #23
Description of the changes being introduced by the pull request:
Add support for Python 3.4, 3.5 and 3.6 (in addition to Python 2.7 support).
Commits whose titles start with
Py2/3
contain all the changes for cross compatibility. The remaining commits update Travis and tox configs to run linters and unittests on all versions and fix coverage issues.Please verify and check that the pull request fulfills the following
requirements: