Remove use of non-public C functions in ctypes_patch #114
Conversation
We can't remove the manual dependency completely yet, but it's better to use a release version than the development version from the repo.
There was a problem hiding this comment.
The approach makes sense. Unfortunately, I'm currently on the road, and Xcode is insisting on me doing an OS upgrade before I can do an Xcode upgrade before I can test this on device 😠 I'll be back in my office in a couple of days and should be able to verify this patch then.
| # FIXME Remove the manual pyflakes dependency once flake8 depends on pyflakes >= 2.0.0. | ||
| # Currently we need to manually update pyflakes in order to use __class__, because pyflakes <= 1.6.0 | ||
| # doesn't understand __class__. This has been fixed in pyflakes 2.0.0, but flake8's requirements don't allow that | ||
| # version of pyflakes yet. |
There was a problem hiding this comment.
Is this comment still valid?
There was a problem hiding this comment.
Yes, flake8's current setup.py only allows pyflakes >= 1.5.0, < 1.7.0. The reason for the upper version limit is explained in the flake8 FAQ.
There was a problem hiding this comment.
Oh - right, now I get it. This is about forcing the pyflakes version because of flake8's stated requirement.
|
@dgelessus FYI - I tried out this patch over the weekend and had no success; however, I wasn't able to get my other "working" example (which commented out the line from the ctypes_patch that cause problems) to work, either... The issue is that this problem only manifests on AdHoc and App Store builds, those take 5-10 minutes each time to prepare, and you completely lose all stdin/stdout debugging assistance when that happens (because, in Apple's wisdom, they've discard all stdin/stdout in favour of their infernal logging framework). I'll have to keep digging... |
I've thought about this before - would it be of any use to provide a custom output stream class in Rubicon, which |
|
@dgelessus In the past I've hacked together something messy to do exactly that. Historically, I've done it at the C level so that I can catch errors that come up as part of Rubicon instantiation; although as long as we can install the handler early enough, I suppose a Python implementation would be sufficient. |
There was a problem hiding this comment.
I'm going to accept this on the basis that it broadly makes sense, and works in CI. It's not resolving my problems with deploying on iOS, but at this point, it's not clear if those problems are being caused by something else, and this patch is necessary for GNUStep support.
This should fix #113.
Also includes a small update to the tox.ini to remove the dependency on the development version of pyflakes.