poetry 1.8: Error installing packages from private artifactory repository #9185
Comments
damonallison
added
kind/bug
looks like a network connectivity problem, not something that can be solved from this repository. |
|
Hey @dimbleby - thanks for looking into this.. I agree it definitely looks like a network connectivity problem. I can assure you that switching to I think the problem is related to jfrog's mis-handling of ranges as described in #9056. I will put some time into debugging jfrog's responses and determine why poetry is timing out on the request. My guess is it's waiting for a chunk that it never receives. |
|
I don't know whether it is making any difference or not, but you shouldn't put this in your pyproject.toml publishable repositories are poetry configuration, not project configuration - https://python-poetry.org/docs/repositories/#publishable-repositories possibly having two repositories with the same domain is confusing things, or possibly not |
|
Thanks again @dimbleby - appreciate the tip.. I removed the publish repo from Also of note: I ran So it appears like this was introduced between |
|
this bit of output
suggests that poetry has understood that whatever it is talking to does not understand ranges and has given up on using them. But of course it is possible for that code to be bugged you could try setting |
|
@dimbleby thanks again for the tip... Setting |
|
Repro steps:
|
|
FWIW I am seeing the same issue on a different private PyPI, also hosted on JFrog artifactory. Poetry v1.8.2
|
|
someone who is hitting this is gonna have to do some debugging themselves I'm afraid. The repro at last-comment-but-one just says that lazy wheel is broken - which obviously is not generally the case. presumably artifactory is doing something odd in response to range requests and poetry is not able to cope with it: but it's going to take someone with access to such a server to investigate |
|
I have access to such a server and can help with some guidance. In my case, it seems to be simply ignoring the Range request header and returning a 200 with the full content. This is despite a |
|
The behavior in #9185 (comment) is expected and does not show a final failure but just correct error handling:
The error handling is triggered by Artifactory's presumably bad behavior described in #9068 (comment). The error handling results in a higher number of network requests, which may overload Artifactory so it times out. 🤷 Currently, we will try range requests again for each wheel (because there are servers that support ranges requests for some wheels and can be trusted regarding the |
|
I also have access to a "bad server" (jfrog artifactory) and can help with some guidance. I'll take an initial stab at trying to distinguish between "good" and "bad" servers and turning off range requests for bad servers. |
|
@SergeyTsaplin please dont hijack issues with something that you know to be different. What you are seeing has getting on for a dozen duplicates by now, but this is not one of them. |
Secrus
added
area/installer
Description
We are running into errors downloading from a private virtual artifactory instance. It appears almost directly related or the same as #9056 - but since that issue looks resolved and released with
1.8.2, I thought I'd report it again.Workarounds
Use
1.7.1or lowerPoetry Installation Method
pipx
Operating System
macOS 14.4
Poetry Version
Poetry (version 1.8.2)
Poetry Configuration
Python Sysconfig
Example pyproject.toml
Poetry Runtime Logs
The text was updated successfully, but these errors were encountered: