-
Notifications
You must be signed in to change notification settings - Fork 2.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
How can I modify REQUESTS_TIMEOUT? #6009
Comments
Not configurable. Do you need it to be configurable? I think an MR would be likely to be accepted. |
We are trying to avoid adding too many configuration options. Could you please provide an example of when this could be useful? |
I'm certainly happy to provide PR. But then again, there are indeed cases where this configuration is useful. For example, when I use docker to build a python program image based on the poetry v1.2.0b3 package manager and have configured the image source. [[tool.poetry.source]]
name = "tsinghua"
url = "https://pypi.tuna.tsinghua.edu.cn/simple"
default = true
[[tool.poetry.source]]
name = "aliyun"
url = "https://mirrors.aliyun.com/pypi/simple"
secondary = true Then there is the following timeout error.
But when I copy the following pip.conf to dir '/home/user/.config/pip', and add the following command to Dockerfile before 'RUN poetry install --only main', and run 'docker build' again, it works. pip.conf
Dockerfile RUN python3 -m pip config --user set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple
RUN python3 -m pip config --user set global.timeout 150 The default value of REQUESTS_TIMEOUT is 15. So I guess if I turn it up, it will take effect. Thanks. |
|
But why does the following errors appear when installing the .tar.gz packages when I use 'RUN poetry install --only main' ?
Only package aioch and requests-aws have this exception, and I configured the mirror source. |
sure, it looks as though you have a networking problem. What I am telling you is that it is happening in a |
Well, thank you very much. Poetry is a good tool! |
Joining here: I have problems publishing my artifacts and there poetry uses exactly this 15s This needs to be adjusted
|
Hey @Secrus, I am having a lot of trouble installing pyspark via poetry due to this hard coded 15s timeout. The pyspark tar.gz is around 280mb, and downloading this from an internal pypi mirror can take longer than the timeout, causing it to retry a couple of times before finally failing. In the past I have got round this by using pip install pyspark --default-timeout 300. I want to use poetry going forward for my projects, but this is unfortunately a blocker! If an approach is agreed I'd be happy to look at implementing a fix PR. Thanks, |
the timeout has nothing to do with how large the file is or how long the download takes; it's about how long it takes to establish a connection / the gap between reads. |
We discussed this in a recent call; consensus right now is an unstable environment variable would be accepted to stop any bleeding (though, in most cases improving an unreliable network is a better move), but would not be documented outside a FAQ/stabilized. Longer-term, it should be part of the same mechanism as #1623 and available as a flag as well. |
FWIW, downgrading to a previous version of Poetry (v1.1.13) seemed to solve the issue for me. I couldn't install pyspark on v1.2.2 due to the 15s timeout errors I was encountering. |
Bumped into the same problem. A config option for such timeout would be great! As suggested using Poetry (v1.1.13) is a viable workaround. |
Same problem today -- very long downloads on large (e.g., numpy, scipy) packages driving 443 timeout in underlying pip execution. It's not my local or area network that's the problem. Downgraded to 1.1.13 and it downloads (very slowly) but doesn't time out. |
There are a lot of misconceptions here -- Poetry does not use pip for downloading in 1.2 or 1.1; unless you set I can tell that everyone here is not locking with 1.1 as 1.1.13 is/was broken by a PyPI change; you should use 1.1.15, the latest 1.1 release, as it contains a fix for the PyPI API's breaking change. In any case, we can add a knob for this temporarily until we have a better fix, and PRs are welcome. I just must stress that your local network configuration is the issue/is partially misbehaving; timeouts are related to how long it takes to establish a connection or to get a reply during a transfer, and not to how long the transfer takes. The transfer is either having trouble being established, or is dropping many packets and timing out. Adding a knob can help stop the bleeding, but fundamentally there are issues with reliable network transfer somewhere on these systems. You can experiment with limiting concurrency with |
Maybe a silly question, but what exactly do you understand as "troubleshoot your local network"? What exactly should I do here?
So the question truly becomes: What exactly happens within poetry thinks the request has timed-out? From my perspective I don't really understand how I can blame the "network" when everything works fine under "poetry<=1.1.13" while a "poetry>2" just reports a timeout. Since nothing in the network has changed in-between the problem is something in poetry (or any of the dependencies used) and not the network in question. I can also give "poetry==1.1.15" a shot, but then what does it mean when this doesn't work? Is the lock-file perhaps not up-to-date? But then a "poetry lock --no-update" doesn't change a thing. PS: |
@neersighted thanks the for the feedback. I understand the issue, though I can't fathom what my local issue might have been. I was in a near panic trying to build on a deadline. Glad there was a funky workaround (which still doesn't make sense why it worked and not ^1.2). I depend heavily on poetry. Amazing project -- super helpful, super easy to compose across repos, I'd be dead without it. |
This is really nice and would help me out! I have quite a large Python package that is uploaded to our internal repository from CI/CD, adjusting the Poetry timeout helps but it is hard to do in CI/CD without this being an option. |
This is where the issue is in my case. I can (very slowly) get to the end of the stream if I increase I can see the point of "not-having-too-many-knobs". I don't see the point of keeping that timeout at What are the drawbacks of increasing that value? I'm questioning the default value, not on whether to configure it or not. |
15 seconds is really a very long time to see no activity whatever from a server. For almost everyone, that's plenty long enough to indicate that something is broken: and therefore a good time to stop. For comparison, pip's equivalent default timeout is... 15 seconds. |
Fair enough, then #7081 is a good idea. Hope it's coming soon and going to stay. |
We are working with poetry behind a corporate proxy. One of the effects is that before sending bytes to whom requested the file, it will be cached and scanned on the proxy. It can be observed as such: after starting the download it will sit for some time at 0% and only after that the actual download will start. When using Please consider merging the PR with an explicit timeout configuration. |
I'm using poetry with docker for local development and with the current timeout it is not very usable if I have packages with larger wheels like I couldn't find a workaround so I reverted back to pip. It would be great if it would be possible to control the timeout or have some other fallback mode to get around this issue. |
Has there been any progress with this request? I understand how some feel like 15 seconds should be a sufficient amount of time in the real world, however; some of us use poetry in large corporations where internal repositories are getting pounded by clueless AI business users who deploy crap that just hammers the servers down to submission. 15 seconds is NOT enough time to even get a container build in these situations. Unfortunately this has been our reality for the past couple of weeks and poetry has become unusable at this point. Poetry is a good tool but flexibility is key for something becoming a great tool. Configuration options are never a bad option for use cases where thousands of applications are impacted by a problem which can be mitigated by giving the developers more control over the behavior of the tool. |
Publishing packages on PyPI using GitHub actions can take longer than expected. Poetry has a timeout of 15 seconds to check for new activity on the network but on GitHub actions sometimes that's not enough. This error was reported on python-poetry/poetry#6009 and it's fixed using the env variable POETRY_REQUESTS_TIMEOUT. We set this variable to 120 seconds that should be more that enough for PyPI to finish the work. Signed-off-by: Santiago Dueñas <sduenas@bitergia.com>
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Issue
The default value of REQUESTS_TIMEOUT is 15. How can I modify REQUESTS_TIMEOUT? Thanks.
The text was updated successfully, but these errors were encountered: