Requested runtime 'python-3.X.Y' is not available for this stack due to hitting curl connection timeouts on Dokku

[DavraYoung]

We faced issue while using this buildpack on our dokku server

remote: =====> Detected Framework: Python        
remote: -----> Using Python version specified in runtime.txt        
remote:        !     Requested runtime 'python-3.10.11' is not available for this stack (heroku-20).        
remote:        !     For supported versions, see: https://devcenter.heroku.com/articles/python-support        
remote:        !     https://heroku-buildpack-python.s3.us-east-1.amazonaws.com/heroku-20/runtimes/python-3.10.10.tar.gz        
remote:  !     Failure during app build        

After some research we found that this happens because of small timeout window set in the curl commands.

For anyone struggling with same issue, you can fork the buildpack and increase the timeout window like I did here

Let me know if PR required

[edmorley]

Hi!

Curl's --connect-timeout refers to the time taken to make the initial connection (once the connection is established the download itself can take as long as it wants). If your Dokku instance isn't able to establish a connection to the remote server within 5 seconds, then it sounds like it's drastically underpowered or has networking issues?

The reason we have the timeouts in place is to stop hangs and force a retry when the initial S3 instance being connected to has issues. We were seeing a bunch of connection issues at one point in CI.

At the moment with our classic buildpacks, the primary use-case is using them remotely on Heroku (rather than locally, or on Dokku). Longer term we're migrating to CNBs (Cloud Native Buildpacks), which can more easily be run locally (by both Heroku customers and others), at which point we'll need to consider slow networking scenarios specifically (one option might be for us to start fronting S3 with a CDN etc).

[DavraYoung]

@edmorley Thank you for taking the time to respond.

Our server is stuck in Tashkent due to project constraints, so we can't change its location. We are trying to resolve the network issue on our side

If the resources allow, please consider at least 5 seconds increase in those values(putting 10 seconds timeout is fine), that will effectively solve our problem

[edmorley]

Sure - I've opened #1439 to raise the limits from 5 to 10 seconds :-)