-
Notifications
You must be signed in to change notification settings - Fork 22
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
Python 3.5 fixes #38
Python 3.5 fixes #38
Conversation
@nedbat @cpennington please review |
2f14ce4
to
24b03b0
Compare
@@ -51,8 +51,8 @@ | |||
}, | |||
|
|||
install_requires=[ | |||
'pylint==1.4.5', | |||
'pylint-django==0.6.1', | |||
'pylint>=1.5.4,<2.0.0', |
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.
Do not unpin pylint. It will cause a world of hurt in edx-platform.
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.
We need 1.5.x for Python 3.5. Hmm...how about I change this to 'pylint>=1.4.5,<2.0.0'
, and add pylint==1.4.5
to edx-platform? That allows for edx-platform to remain stable, and other users to get the latest compatible version. We also don't have to touch this package again just to update Pylint.
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.
When I saw this pull request, I thought, "wait, didn't we do 3.5 already? Oh yeah, there was something that made it difficult." This is the thing. We could pin the version of pylint in edx-platform, but there's a larger problem: it's natural for pylint to add new checkers in new versions. This means that when pylint upgrades, there will likely be more violations found. Builds that depend on not exceeding some threshold of violations will then break. We don't want pin-ranges to mean that we could silently upgrade something that will break our builds. I'm not sure what to do about this.
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.
Pinning pylint here makes this library fragile. I'd rather consuming applications, especially edx-platform, pin pylint instead.
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 not sure how pinning makes it fragile? Part of the original goal of edx-lint was to ensure that all of our repos were linted the same. It does that mostly by using a common pylintrc, but a pinned pylint version can also help. So far, there doesn't seem to be a problem that is solved by unpinning pylint, so can we leave it pinned?
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.
We can pin to 1.5.4.
The tests don't pass for me locally on Python 3.5:
I think the Travis builds are only running pylint? |
Locally, master passes on 2.7 and 3.5, and I am running with pylint 1.4.5. What problems were you seeing? |
Weird. This worked last night on my personal machine (3.5.?), and still works on Travis (3.5.0). It fails on my edX machine with Python 3.5.0. |
- python: "2.7" | ||
env: TOXARG="-e pylint" | ||
env: | ||
- TOXARG="-e pylint" |
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.
This line made it so that Travis doesn't run tests, it only runs pylint.
Backstory: I'm working on a new library,
I have no issues when I manually update Pylint from 1.4.5 to 1.5.4. That's the actual issue I need to resolve here. I'm not sure what happened last night with the bytes vs. string issue, prompting me to update that code; but, it is no longer an issue. I am reverting those changes now. |
24b03b0
to
b90a960
Compare
I've found the disconnect. The tests certainly work; however, in practice
|
b99e9b1
to
f1a7092
Compare
ECOM-3765
78d4f01
to
b66f228
Compare
@@ -34,6 +34,10 @@ def write(self, text, hashline=b"# {}"): | |||
to the file, with "{}" replaced with the hash. | |||
|
|||
""" | |||
# Ensure we are working with bytes. | |||
if isinstance(text, str): | |||
text = str.encode(text) |
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.
This seems wrong for py2, where we expect a "str", and the .encode will do the wrong thing for non-ascii. The argument is documented as a bytestring, so why do we need these lines?
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.
The argument being passed when running the command is of type str
: https://github.com/edx/edx-lint/blob/master/edx_lint/cmd/write.py#L123. Perhaps a better solution is to update this method to accept str
instead of bytes
?
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.
Or remove the str
from that line in write.py
22f3821
to
0e0d183
Compare
""" | ||
return main.main(argv) | ||
|
||
@unittest.skip('Default test runners have issues finding the file.') |
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.
Note that I've added a test that is broken for everything but PyCharm. Still trying to figure out why.
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.
#39 filed to address this issue in the future.
ECOM-3765
ECOM-3765
ECOM-3765
0e0d183
to
26cbe50
Compare
@nedbat let me know if you have additional feedback, or if we are good to merge. |
@nedbat are we good to merge? |
I have a feeling of dread about this, but I don't have a better solution, so 👍 |
🙊 |
ECOM-3765