-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Upgrade to httpbin 0.10.0 #6496
Conversation
The PyPy 3.8 Windows build seems to be consistently timing out at 10 min because it's trying to build wheels for a handful of dependencies and installation is taking ~8 min of the run. We may need to either bump the time limit or see if there's a way we can get the installation step sped up. Edit: It succeeded on the third retry. zope.interfaces, flasgger, and rpds_py seem to be the time intensive builds for wheels. I'm not sure if we can optimize this at all or if this is just a requirement to operate with PyPy. If this becomes a reoccurring issue, I'd be fine dropping back to fewer PyPy builds if there's not a clear solution. |
Why can't we cache the wheels that are built so subsequent runs are faster/less likely to time out? |
3095814
to
f331c63
Compare
TIL this was an option. I've pushed up a change to enable it and we'll see if speed improves. |
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Enable pip caching in order to avoid repeatedly rebuilding all the PyPy wheels for source packages. This is inspired by discussion in psf/requests#6496 and it may help with the PyPy CI failures.
Looking at the builds, the expensive wheels don't look like they're going to take advantage of the cache. They all have unique ABI for each platform and version of PyPy.
The issues seem isolated to Windows and showed up on the 3.12-dev builds too. It also was happening with other builds so it's not unique to the httpbin changes. I'll merge the cache change because it appears to have some minor improvements for the other builds. I also see @mgorny is working on a more involved fix in psf/httpbin to deal with windows. I'd rather forego those for now and bump the timeout to 12 min which seems to be the upper bound for the builds that are currently failing. We can reevaluate if it becomes a nuisance. |
This PR will upgrade the Requests test suite to use the recently released httpbin 0.10.0 that now supports the latest major version of Flask. This will let us remove our pins on pallets projects and hopefully allow distro maintainers to no longer need to support these older versions.
Thanks @mgorny and @kevin1024 for helping get this unblocked and closing out #6070!