Why POETRY_REQUESTS_TIMEOUT is experimental

[Zaczero]

It seems this 1-liner feature was added an over a year ago in #7081. After trying it out it significantly improved reliability of installing packages via poetry. My questions is: What exactly needs to be done for this feature not to be experimental? I haven't found any discussion/issues around it. Is it safe to use?

But also, why is the default timeout 15 seconds? I don't think Poetry is a time critical software and it should prioritize installing packages even during a connection slow down rather than aborting it half-way. Could it be increased to a more reasonable 30 seconds? Alternatively, could we have a download resume functionality so it doesn't keep redownloading big packages from the beginning?

[radoering]

My questions is: What exactly needs to be done for this feature not to be experimental?

It can only be configured with an environment variable, not via poetry config. All other settings can be configured via poetry config so I suppose implementing complete support for this setting is missing yet

I haven't found any discussion/issues around it. Is it safe to use?

I think so. The name may change if we make it a real setting at some point - even though I think we will keep this name because it fits well (cf #9422 (comment), this PR introduced requests.max-retries so that requests.timeout fits well).

But also, why is the default timeout 15 seconds?

Because that is the same as pip, see https://python-poetry.org/docs/faq/#my-requests-are-timing-out.

Could it be increased to a more reasonable 30 seconds?

It is probably very controversial what a reasonable default value is. That is why we chose the same value as pip and made it configurable.

Alternatively, could we have a download resume functionality so it doesn't keep redownloading big packages from the beginning?

You are probably asking for #9422, which has been merged into main yesterday.

[Zaczero]

It's really rare to see such good answers. Thanks a lot and have a great day!