-
Notifications
You must be signed in to change notification settings - Fork 28
Run tests against Python 3.7, too #70
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
Conversation
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 we should keep sudo off where possible.
https://github.com/Pike/compare-locales/blob/dd90f1b2941b9c774418ece6a4ae9308e1db6176/.travis.yml shows how to do that.
Thanks for the pointer. I didn't know it was possible to have different OS setups in |
.travis.yml
Outdated
include: | ||
- python: 2.7 | ||
dist: trusty | ||
sudo: false |
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.
(passing by, interested question) Do you really need to repeat the sudo: false
, when it's declared at the beginning of the file? Logically, only the 3.7 one would need an override
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 should test on both nightly and 3.7, I think.
Also, with the recent changes to .travis.yml, this needs work?
(Sorry for the lack of response.)
Ugh, I don't understand the Travis and Tox combo. I'll be happy to cede this issue to you, @Pike, if you have ideas on how to fix it. I enabled |
I also opened #89 to investigate whether we need Tox at all. |
Seems that xenial defaults to a buggy version of pypy. Let's try 6.0, which is the latest release.
Yes, sadly. Filed #90 on that. |
Thanks for looking into the |
I'd say yes, I think it does two things for us: One, it's getting us the latest release that we'd end up with locally. The other is, it's pinning us to that release, so we're not getting back in the same boat we were in here, that a change of pypy under the hood breaks our tests, w/out actually being attributed to a pypy change. We should also add back |
OK, thanks for the help. I think this is good to land now. It ended up being a very simple PR :) |
No description provided.