Skip to content

Conversation

@clavedeluna
Copy link

I'm not sure if this is possible at this time, but I'm working with the uv package manager and having so many problems trying to install vcrpy==7.0.0 with other packages needing urllib3>2. Removing this dependency here fixed all my issues.

@adamJLev
Copy link

Agreed, not sure what the best fix is here but im having some pain now with this too

$ poetry env info

Virtualenv
Python:         3.13.3
Implementation: CPython
Path:           /Users/ajl/Library/Caches/pypoetry/virtualenvs/project-bZWYOXtw-py3.13
Executable:     /Users/ajl/Library/Caches/pypoetry/virtualenvs/project-bZWYOXtw-py3.13/bin/python
Valid:          True

$ poetry lock  && poetry install --with=dev
Resolving dependencies... (0.2s)

Because vcrpy (7.0.0) depends on urllib3 (<2)
 and project depends on urllib3 (>2.0.0), vcrpy is forbidden.
So, because project depends on vcrpy (7.0.0), version solving failed.

@Abello966
Copy link

Abello966 commented Jun 20, 2025

signal-boosting this because there is a CVE relating to urllib<2.5.0

https://nvd.nist.gov/vuln/detail/CVE-2025-50182

@deeleeramone
Copy link

Bumping for visibility here. Requirement pinning urllib3 < 2 is blocking lots of security and package updates - and is quite unnecessary.

"urllib3 <2; platform_python_implementation =='PyPy'",

@clavedeluna
Copy link
Author

bump, could we get this merged and released? 🙏

Copy link
Contributor

@CharString CharString left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As suggested this PR breaks things. But CPython < 3.10 is end-of-life and the end of this month. So we could set python_requires=">3.10" and drop the
"urllib3 <2; python_version <'3.10'", and "urllib3; platform_python_implementation !='PyPy' and python_version >='3.10'", lines.

As for the pypy pin:

I've tested pypy3.11-7.3.20 against urllib3 2.5.0 and it works.

But I failed to run them on pypy3.10-7.3.19:

help: rpds-py (v0.28.0) was included because vcrpy[tests] (v7.0.0) depends on pytest-httpbin (v2.1.0) which depends on httpbin (v0.10.1) which depends on flasgger (v0.9.7.1) which depends on jsonschema (v4.25.1) which depends on rpds-py

So if we want to keep supporting it we need to add a pin for jsonschema< 4.18; platform_python_implementation == 'PyPy' and python_version <='3.10' in the extras_require too. Then we can narrow the pin on urllib3 to urllib3 <2; platform_python_implementation =='PyPy and python_version <='3.10'

At the very least set python_requires=">3.10".

@CharString
Copy link
Contributor

signal-boosting this because there is a CVE relating to urllib<2.5.0

https://nvd.nist.gov/vuln/detail/CVE-2025-50182

That CVE is regarding 2.2.0 <= urllib3 < 2.5.0. There is nothing in these pins that pins anyone to a vulnerable version.

And that bug in poetry dependency resolution ought to be solved in poetry not in the rest of the whole ecosystem.

@piiq
Copy link

piiq commented Oct 28, 2025

For anyone looking for a solution:

  1. On the poetry side: you can include the markers into the dependency definition in the pyproject.toml to prevent old urllib3 version leaking into the lock file or the environment. For example:
vcrpy = { version = ">=7", markers = "platform_python_implementation == 'CPython'" }
  1. On the uv side: you can use the dependency override feature by specifying the platform and supported python version for a specific dependency. Here's a minimalistic pyproject.toml that will get you a uv.lock that doesn't mention the old version of urllib3
[project]
name = "temp"
version = "0.1.0"
authors = [{ name = "piiq", email = "[email protected]" }]
requires-python = ">=3.12"
dependencies = ["vcrpy>=7.0.0"]


[tool.uv]
override-dependencies = [
    "urllib3>=2 ; implementation_name == 'cpython' and python_version >= '3.12'",
]

P.S. If this works for you feel free to link to this comment elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants