ERROR:pip_audit._cli:impossible resolution after upgrading to 2.4.15

[khink]

Bug description

2.4.15 introduced an error for us while running the pip-audit:

After upgrading to pip-audit 2.4.15 (this was the only change), pip-audit failed with this error:

ERROR:pip_audit._cli:impossible resolution: [RequirementInformation(requirement=<Requirement('django==3.2.16')>, parent=None), RequirementInformation(requirement=<Requirement('Django>=3.2')>, parent=<dj-database-url==1.2.0 wheel=True>), RequirementInformation(requirement=<Requirement('Django>=2.2')>, parent=<django-allow-cidr==0.6.0 wheel=True>), RequirementInformation(requirement=<Requirement('Django>=2.2')>, parent=<django-amazon-ses==4.0.1 wheel=True>), RequirementInformation(requirement=<Requirement('Django==4.1.5')>, parent=<django-extra-views==0.13.0 wheel=False>)]

Pinning pip-audit to 2.4.14 fixes it.

Reproduction steps

The attached requirements file reproduces it:

development.txt

python3.11 -m venv env
source env/bin/activate
pip install pip-audit==2.4.15
python -m pip_audit --strict --desc on --requirement development.txt

Expected behavior

I'd expect pip-audit to only complain about outdated dependencies. Instead, we get ERROR:pip_audit._cli:impossible resolution

Platform information

• Ubuntu 22.04, Debian Buster
• pip-audit version 2.4.15
• Python version: 3.11
• pip version: 23.0

More context

• The requirements file was generated using pip-tools.
• I also notice 2.4.15 is a lot slower than its predecessor.

[woodruffw]

Thanks for the report @khink!

I'm looking into this now.

[woodruffw]

• I also notice 2.4.15 is a lot slower than its predecessor.

I can also confirm this: looks like performance regressed by 4-5x during the last release.

[woodruffw]

Educated guess is that this was caused by #488, with the performance regression possibly being also caused by #462.

[woodruffw]

I get a different resolution conflict, although it's probably the same root cause:

$ pip-audit --strict -r ~/Downloads/development.txt 
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:pip_audit._dependency_source.resolvelib.pypi_provider:invalid specifier set for Python version: >=3.6.*
WARNING:pip_audit._dependency_source.resolvelib.pypi_provider:invalid specifier set for Python version: >=3.6.*
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
WARNING:cachecontrol.controller:Cache entry deserialization failed, entry ignored
ERROR:pip_audit._cli:impossible resolution: [RequirementInformation(requirement=<Requirement('flake8==6.0.0')>, parent=None)]

Even in --require-hashes mode, which skips all resolution:

$ pip-audit --require-hashes -r ~/Downloads/development.txt 
WARNING:pip_audit._dependency_source.resolvelib.pypi_provider:invalid specifier set for Python version: >=3.6.*
WARNING:pip_audit._dependency_source.resolvelib.pypi_provider:invalid specifier set for Python version: >=3.6.*
ERROR:pip_audit._cli:impossible resolution: [RequirementInformation(requirement=<Requirement('flake8==6.0.0')>, parent=None)]

[woodruffw]

Hmm, stepping back a bit, it looks like we have a separate regression: --require-hashes (or a fully hashed input, like yours) should disable dependency resolution entirely (and therefore be almost instantaneous), but we're still triggering it. Looking into that now.

[woodruffw]

Looking at it some more, I think #462 is the root cause here: we accidentally regressed the behavior of --require-hashes so that it now does full dependency resolution, which (1) takes far longer, and (2) appears to be buggy (possibly because of #488).

#462 was a somewhat involved change, so I don't think we can cleanly revert it. Instead, I'm going to yank the current 2.4.15 release and work on adjusting it.

[woodruffw]

Okay, 2.4.15 has been yanked, and I'll continue with a fix. In the mean time, a temporary workaround with any pinned 2.4.15 versions is to also pass --no-deps.

[tetsuo-cpp]

The dependency resolution bug here is captured in #522.

[woodruffw]

This should be addressed by the refactor we've done in #523.