-
-
Notifications
You must be signed in to change notification settings - Fork 177
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
Start testing PyPy #357
Start testing PyPy #357
Conversation
@willmcgugan do you know anything about the MyPy failures? |
No, they appeared recently. It's on my list to take a look at. I'm traveling atm. Back next week. |
seems like the recent version of |
Should we pin it to an earlier version for now? |
Dissecting the version show that the new build fails with |
I think I'd prefer to ignore those errors rather than pin to older Mypy. The factory pattern is a little unorthodox, but I wouldn't say it's a bug. |
@willmcgugan : same, this can be ignored IMO. |
I know nothing about MyPy, but is it worth reporting a bug / feature-request asking them to support the "unorthodox factory pattern" being used in PyFilesystem? Or is a "local ignore" the only sensible way around this? |
I reckon 99% of the time that would be a bug. So Mypy is right to flag it, but we have a legit reason to ignore those errors. I'll review that code though. Maybe there is a way of making it less unorthodox that Mypy approves of. |
I forgot we can do that 😄 |
Thanks @dargueta |
Type of changes
Checklist
Description
There's a problem with the SFTP server daemon in our tests that causes PyPy to fail on them (see #342). We can still test PyPy compatibility with other parts of the codebase without failing the build by using Travis'
allow_failures
directive. This will still run tests on PyPy, but won't fail the build if the PyPy builds don't pass. We can remove theallow_failures
part once #342 is fixed.