CI: Reduce pip behaviour dependencies in test suite

[ncoghlan]

Closes #2104

Contributor checklist

• Included tests for the changes (change is to fix a test).
• PR title is short, clear, and ready to be included in the user-facing changelog.

Maintainer checklist

• Verified one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[webknjaz]

@ncoghlan could you check if this is still necessary? pip is now pinned to 24.2 in regular CI runs, and the CI has been made green with that (see #2140).

[ncoghlan]

Given CI is green, I agree it isn't necessary to proceed with this.

[webknjaz]

@ncoghlan note that the pip version in CI is now restricted so that the updates are transparent. So it is possible that this breaks with newer pips (I know there are some problems; I just don't know if they are the same you were looking to address here).

[ncoghlan]

Ah, in that case you will still need something along these lines when upgrading to a newer pip. The specific changes this made are to:

• explicitly set a build system and constraint file in test_compile_recursive_extras_build_targets
• remove setuptools, wheel and distribute from the expected set of protected modules in test_diff_should_not_uninstall

[ncoghlan]

This will be an interesting test to see if my changes actually broke compatibility with the older pip version.

My prediction: the explicit build system change will be OK, but the protected file list test case will fail (since the older pip still protects those packages)

[webknjaz]

What if this was to be made conditional? Perhaps, the test could be parametrized with variants before and after certain pip version that would run in different jobs (through the skipif mark). It'd be able to cover the concern of breaking on older versions…

[webknjaz]

With pip 25.3+, we'd need PIP_BUILD_CONSTRAINT.

[webknjaz]

@ncoghlan do you think this is still relevant?

cc @sirosen

[sirosen]

I have spent quite a while staring at this and trying to decide whether or not there's anything we should keep in the PIP_CONSTRAINT change.

Because we now parse pyproject.toml statically where possible, the original issue doesn't apply anymore, at least if I'm reading things correctly.
I find the test in question (test_compile_recursive_extras_build_targets) to be unclear in purpose -- it seems to be one of a small number of happy-path tests for --build-deps-for, but it also involves self-referential extras. So I'm not sure that I'm correctly reading what it's trying to test?

In any case, I've filed #2336 with what I think is the usable part of this, and I'm closing as having been addressed across #2188 and various other changes.