Skip to content

Turn PipDeprecationWarning into errors when running tests#13947

Open
danielhollas wants to merge 3 commits into
pypa:mainfrom
danielhollas:error-on-pip-warnings
Open

Turn PipDeprecationWarning into errors when running tests#13947
danielhollas wants to merge 3 commits into
pypa:mainfrom
danielhollas:error-on-pip-warnings

Conversation

@danielhollas

Copy link
Copy Markdown
Contributor

This is motivated by #13912, which added a PipDeprecationWarning for unexpected lazy imports during installation. But these warnings could slip through the test suite if some future change in pip introduced such an import. In this PR I propose to turn all PipDeprecationWarnings into errors using pytest configuration. If this too broad, we can make it more specific by only targetting the warning added in #12912.

This is an internal-only change so I don't think needs a NEWS entry.

@danielhollas danielhollas marked this pull request as ready for review April 25, 2026 19:26
@ichard26 ichard26 added the skip news Does not need a NEWS file entry (eg: trivial changes) label Apr 25, 2026
@notatallshaw

Copy link
Copy Markdown
Member

Thanks for this, it was going to be the next thing I did, I played around with this approach and found it doesn't help functional tests that call pip as a subprocess, as the pytest machinery is lost there.

I was playing around with this and I think a good approach is to have src/pip/_internal/utils/deprecation.py:install_warning_logger raise pip warnings to errors when there a given env var available, and then in tests/lib/__init__.py:PipTestEnvironment.__init__ set that env var. A couple of warning tests will need to pip that env var.

But open to ideas.

@danielhollas

danielhollas commented Apr 26, 2026

Copy link
Copy Markdown
Contributor Author

Good point about subprocesses. I likely won't have time to push this further over the next three weeks, feel free to push to this PR or open a new one. (I guess the pytest setting I have here still seems useful even if it doesn't cover everything).

@danielhollas danielhollas force-pushed the error-on-pip-warnings branch from c8f406e to 808bc14 Compare May 30, 2026 13:34
@danielhollas

Copy link
Copy Markdown
Contributor Author

I was playing around with this and I think a good approach is to have src/pip/_internal/utils/deprecation.py:install_warning_logger raise pip warnings to errors when there a given env var available, and then in tests/lib/init.py:PipTestEnvironment.init set that env var. A couple of warning tests will need to pip that env var.

@notatallshaw I've implemented this approach, I think it works well. Let me know what you think. I was not sure how to name this env var, happy to adjust it.

We could even think about making such a variable public-facing, as I can imagine some users of PIP (e.g. in CI) might want to turn pip warnings into errors as well. But I'd rather keep that discussing for a separate PR if wanted.

Comment on lines +52 to +56
# If we're running pip test suite, promote the PipDeprecationWarning into errors.
if os.environ.get("PIP_TEST_ENV", None):
warnings.simplefilter("error", PipDeprecationWarning)
else:
warnings.simplefilter("default", PipDeprecationWarning, append=True)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Now that I think about this, we could have a variable PIPWARNINGS and have it behave in the same way as PYTHONWARNINGS?

Suggested change
# If we're running pip test suite, promote the PipDeprecationWarning into errors.
if os.environ.get("PIP_TEST_ENV", None):
warnings.simplefilter("error", PipDeprecationWarning)
else:
warnings.simplefilter("default", PipDeprecationWarning, append=True)
action = os.environ.get("PIPWARNINGS", "default"):
try:
warnings.simplefilter(action, PipDeprecationWarning, append=True)
except ValueError as e:
warnings.warn("Invalid PIPWARNINGS variable ignored: {e}")
warnings.simplefilter("default", PipDeprecationWarning, append=True)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'd much rather prefer that we keep the envvar private. I don't immediately see why external users would use it, but let's discourage it while we can.

@notatallshaw

Copy link
Copy Markdown
Member

Thanks, I won't be able to review anything for at least a couple of weeks, but it's high on my review list once I get some time.

@ichard26 ichard26 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks generally good, but I want @notatallshaw's second opinion. I'm not sure about the envvar naming, in particular.

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

Labels

skip news Does not need a NEWS file entry (eg: trivial changes)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants