Implement compatibility with pip 25.3

[shifqu]

Removed use_pep517 reference to enable compatibility with pip 25.3+

Resolves #2252.

Contributor checklist

• Included tests for the changes.
• A change note is created in changelog.d/ (see changelog.d/README.md for instructions) or the PR text says "no changelog needed".

Maintainer checklist

• If no changelog is needed, apply the skip-changelog label.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[shifqu]

I don't think a test is required as it's a bugfix that depends on upstream pip. If I do need to include a test, say the word and I will give it a go.

[shifqu]

closes #2252

[webknjaz]

Thanks for starting this effort!

Here's a few other things that are required to make this mergeable:

• Bump 25.2 to 25.3 in the supported marker in tox.ini — so that we're actually testing this change in CI
• Deprecate the --use-pep517, at least when pip is 25.3+ with a plan to drop in from the user-facing CLI later. Add a deprecation change note about this.
• Have a regression test for the change or make sure that it is already covered elsewhere (having the CLI setting true/false); plus a test for the deprecation.

[shifqu]

Thanks for starting this effort!

Here's a few other things that are required to make this mergeable:

• Bump 25.2 to 25.3 in the supported marker in tox.ini — so that we're actually testing this change in CI
• Deprecate the --use-pep517, at least when pip is 25.3+ with a plan to drop in from the user-facing CLI later. Add a deprecation change note about this.
• Have a regression test for the change or make sure that it is already covered elsewhere (having the CLI setting true/false); plus a test for the deprecation.

I have bumped. Could you provide some guidance for the deprecation? The use-pep517 option was never explicitly supported and thus, is never actually mentioned.

I will check the tests whenever the check check has completed so we can see the report on it

[webknjaz]

• Deprecate the --use-pep517, at least when pip is 25.3+ with a plan to drop in from the user-facing CLI later. Add a deprecation change note about this.

Could you provide some guidance for the deprecation? The use-pep517 option was never explicitly supported and thus, is never actually mentioned.

@shifqu are you saying this is coming from --pip-args and not our own CLI parser? If that's the case, maybe we don't need a deprecation but should probably warn or error out when pip is incompatible. And we could mention the practical impact of this in the change note as well.

• Have a regression test for the change or make sure that it is already covered elsewhere (having the CLI setting true/false); plus a test for the deprecation.
  I will check the tests whenever the check check has completed so we can see the report on it

I approved the CI run and it's now evident that a bunch of other tests are failing. Things like AttributeError("'InstallRequirement' object has no attribute 'global_options'") pop up in the logs, maybe more. So it looks like the scope of this PR will have to be expanded to cover those as well.

P.S. Note that if you're planning to stick around and get involved more, you can log in at https://jazzband.co to join the org. This will result in you not having to go through the CI approvals. Alternatively, if you get some other small PR merged, GH will stop requiring approvals in your following PRs too.

[webknjaz]

@shifqu FYI you should be able to reproduce the failures locally with something like tox r -e pipsupported -qq.

[shifqu]

• Deprecate the --use-pep517, at least when pip is 25.3+ with a plan to drop in from the user-facing CLI later. Add a deprecation change note about this.

Could you provide some guidance for the deprecation? The use-pep517 option was never explicitly supported and thus, is never actually mentioned.

@shifqu are you saying this is coming from --pip-args and not our own CLI parser? If that's the case, maybe we don't need a deprecation but should probably warn or error out when pip is incompatible. And we could mention the practical impact of this in the change note as well.

Indeed, this is coming from pip-args. I will check to see where exactly we can warn or error out.

• Have a regression test for the change or make sure that it is already covered elsewhere (having the CLI setting true/false); plus a test for the deprecation.
  I will check the tests whenever the check check has completed so we can see the report on it

I approved the CI run and it's now evident that a bunch of other tests are failing. Things like AttributeError("'InstallRequirement' object has no attribute 'global_options'") pop up in the logs, maybe more. So it looks like the scope of this PR will have to be expanded to cover those as well.

P.S. Note that if you're planning to stick around and get involved more, you can log in at https://jazzband.co to join the org. This will result in you not having to go through the CI approvals. Alternatively, if you get some other small PR merged, GH will stop requiring approvals in your following PRs too.

Thanks, I have joined jazzband and ran the CI. Still some failures, but they are somewhat cryptic to me. The global_options one was very clear, but here it just says pip has failed. I am looking into it locally though, as I can reproduce there.

[webknjaz]

Still some failures, but they are somewhat cryptic to me. The global_options one was very clear, but here it just says pip has failed. I am looking into it locally though, as I can reproduce there.

Yeah, I find it a bit annoying having to go through the Click testing layer when things fail. Here's how the CLI entrypoints are invoked: https://click.palletsprojects.com/en/stable/testing/ / https://click.palletsprojects.com/en/stable/api/#testing.

Sometimes, running a single test with breakpoint() ans/or pdb is helpful enough to get me through what's happening. I normally run something like tox r -e pipsupported -qq -- -n0 --no-cov -svvvvvv --pdb --full-trace --showlocals 'tests/test_cli_compile.py::test_locally_available_editable_package_is_not_archived_in_cache_dir[legacy]' to get me maximum visibility into things, and then poke around with the debugger.

[webknjaz]

@shifqu I've extended the CI output in #2254. We can get it in if you approve the PR. And then, your updates here will get a lot more additional output upon rebase.

[shifqu]

So locally I have found out that for some tests the output is Could not find setuptools>=40.8.0. A quick search showed me that pip has an open issue for this: pypa/pip#12050. Do we have to rebuild our whl files or something?

[webknjaz]

@shifqu not sure — do you have a log to post? Any isolated repro?

[shifqu]

@webknjaz yes -- I have rebased the rerun failed tests in this PR and the outputs show the same thing. For tests with legacy resolver the setuptools error is present, for backtracking resolver tests, it shows a more generic, less useful error.

FAILED tests/test_cli_compile.py::test_local_file_uri_package[legacy resolver-generate_hashes1-Local project with subdirectory] - AssertionError: assert 1 == 0
 +  where 1 = <Result <InstallationSubprocessError(reference='subprocess-exited-with-error', message='[green]installing build dependencies for small-fake-a[/] did not run successfully.\nexit code: 1', context=<text '[4 lines of output]\nLooking in links: /Users/runner/work/pip-tools/pip-tools/tests/test_data/minimal_wheels, /Users/runner/work/pip-tools/pip-tools/tests/test_data/minimal_wheels\n\x1b[31mERROR: Could not find a version that satisfies the requirement setuptools>=40.8.0 (from versions: none)\x1b[0m\x1b[31m\n\x1b[0m\x1b[31mERROR: No matching distribution found for setuptools>=40.8.0\x1b[0m\x1b[31m\n\x1b[0m\n[end of output]' [Span(0, 19, 'red'), Span(381, 396, 'red')] ''>, note_stmt='This error originates from a subprocess, and is likely not a problem with pip.', hint_stmt=None)>>.exit_code
FAILED tests/test_cli_compile.py::test_local_file_uri_package[backtracking resolver-generate_hashes0-Local project URI] - assert 1 == 0
 +  where 1 = <Result FailedToPrepareCandidate("Failed to build 'file:///Users/runner/work/pip-tools/pip-tools/tests/test_data/packages/small_fake_with_deps' when installing build dependencies")>.exit_code

To reproduce locally with pdb I used the same command you suggested:
tox r -e pipsupported -qq -- -n0 --no-cov -svvvvvv --pdb --full-trace --showlocals 'tests/test_cli_compile.py::test_local_file_uri_package[backtracking resolver-generate_hashes0-Local project URI]'
and
tox r -e pipsupported -qq -- -n0 --no-cov -svvvvvv --pdb --full-trace --showlocals 'tests/test_cli_compile.py::test_local_file_uri_package[legacy resolver-generate_hashes1-Local project with subdirectory]'

The commands are for the failing tests I pasted above. One for backtracking and one for legacy respectively.

Unfortunately I am unable to make much of these errors as I don't have a very good understanding of the tests (yet)

Edit:
I checked the out.output of the backtracking error and it gives the same as the legacy output.

(Pdb) out.output
'    error: subprocess-exited-with-error\n    \n    × installing build dependencies did not run successfully.\n    │ exit code: 1\n    ╰─> [3 lines of output]\n        Looking in links: redacted\\pip-tools\\tests\\test_data\\minimal_wheels, redacted\\pip-tools\\tests\\test_data\\minimal_wheels\n        ERROR: Could not find a version that satisfies the requirement setuptools>=40.8.0 (from versions: none)\n        ERROR: No matching distribution found for setuptools>=40.8.0\n        [end of output]\n    \n    note: This error originates from a subprocess, and is likely not a problem with pip.\n'

[webknjaz]

@sirosen yeah, I suppose. It's easier to pass a --fail-under=98 into pytest in that env, though. As for strictness, I think it's fine, we just need to integrate a better way to mark conditional expectations.

[sirosen]

It's easier to pass a --fail-under=98 into pytest in that env, though.

🤦 Yep, totally easier than what I suggested!
There are a few ways it could be phrased. Looking at our tox config, I think the simplest is

-commands = pytest {posargs}
+commands =
+    py38: pytest --fail-under=98 {posargs}
+    !py38: pytest {posargs}

Does that seem right? Maybe there's a better way?

---

I'll open a separate issue for tracking the idea of doing this via a coverage plugin, so that we can handle more cases as they crop up.

[webknjaz]

Maybe there's a better way?

set_env =
  py38: PYTEST_ADDOPTS = {env:PYTEST_ADDOPTS} --fail-under=98

[sirosen]

If that works it's preferable. I wasn't sure if tox respects that layered with the existing setenv setting for the coverage factor. If they layer correctly, that would be great.

[shifqu]

So would that mean in tox.ini under setenv?

setenv =
    coverage: PYTEST_ADDOPTS=--strict-markers --doctest-modules --cov --cov-report=term-missing --cov-report=xml {env:PYTEST_ADDOPTS:}
    py38: PYTEST_ADDOPTS=--fail-under=98

As I think the coverage layer would have all the options and take the pytest_addopts from env.

[webknjaz]

You're right. set_env would be overshadowed. I don't think it'd be merged. So we should apply it on the commands level as suggested earlier.

[webknjaz]

@sirosen I also realized the Python 3.8 jobs seem to skip the codecov coverage upload step. So I can't see what it is that isn't covered in that env. I suppose it's those pip version conditionals as they also coincide with Pip dropping support for Python 3.8.

[webknjaz]

Wonder if this doesn't work due to TOXENV=pipsupported-coverage rather than py38. Hopefully, using those pragmas (https://github.com/jazzband/pip-tools/pull/2253/files#r2501228610) will help.

[webknjaz]

I also realized the Python 3.8 jobs seem to skip the codecov coverage upload step.

🤔 Looks like this is only happening for failures.. I should add a !cancelled() into the condition, it seems.

[webknjaz]

@shifqu I've added the pragmas you missed. Will see if that will handle the CI properly..

[shifqu]

Ah sorry, @webknjaz , I missed those indeed. Lol, one more check failing. FAIL Required test coverage of 99.0% not reached. Total coverage: 98.99% 0.01% 😢

[webknjaz]

Lol, one more check failing. FAIL Required test coverage of 99.0% not reached. Total coverage: 98.99% 0.01% 😢

That's exactly why we need conditional pragmas everywhere and the target of 100%. Without that, the ratio of covered lines to the total number is unstable (because the total number of lines changes, even if your patch is 100% covered).

[webknjaz]

@sirosen perhaps we should look into adding pragmas everywhere as a prerequisite for this PR? https://app.codecov.io/gh/jazzband/pip-tools/commit/30ed5888bba3f68026592b89a257281fec5b940f/tree?search=&displayType=list shows 9 partials and 12 fully uncovered lines. This seems doable.