Test failure when environment is EXTERNALLY-MANAGED

[christian-heusel]

Description

Hello everyone! 👋🏻 I package pip for Arch Linux and just noticed that the tests for the update check have not been adapted for the new EXTERNALLY-MANAGED / PEP 668 behaviour:

Bug Fixes:

• The pip version self check is disabled on EXTERNALLY-MANAGED environments. (Disable upgrade prompt on EXTERNALLY-MANAGED environments #11820)

This results in a test failure for the new version (see the outputs below).

cc @dvzrv

Expected behavior

No tests fail.

pip version

25.0

Python version

3.13.1

OS

Arch Linux (rolling)

How to Reproduce

1. Have an environment that is EXTERNALLY-MANAGED
2. Build the new pip release in it
3. run the tests
4. observe the failure

The detailed Build recipe can be found here: https://gitlab.archlinux.org/archlinux/packaging/packages/python-pip/-/blob/main/PKGBUILD?ref_type=heads

Output

(I think) This results in the following test failure:

tests/unit/test_self_check_outdated.py::test_pip_self_version_check_calls_underlying_implementation FAILED [ 65%]
[...]
=================================== FAILURES ===================================
_________ test_pip_self_version_check_calls_underlying_implementation __________

mocked_state = <MagicMock name='SelfCheckState' id='133415676229152'>
mocked_function = <MagicMock name='_self_version_check_logic' id='133415676228816'>
tmpdir = PosixPath('/tmp/pytest-of-builduser/pytest-0/test_pip_self_version_check_ca0')

    @freeze_time("1970-01-02T11:00:00Z")
    @patch("pip._internal.self_outdated_check._self_version_check_logic")
    @patch("pip._internal.self_outdated_check.SelfCheckState")
    def test_pip_self_version_check_calls_underlying_implementation(
        mocked_state: Mock, mocked_function: Mock, tmpdir: Path
    ) -> None:
        # GIVEN
        mock_session = Mock()
        fake_options = Values({"cache_dir": str(tmpdir)})
        mocked_function.return_value = None
    
        # WHEN
        self_outdated_check.pip_self_version_check(mock_session, fake_options)
    
        # THEN
>       mocked_state.assert_called_once_with(cache_dir=str(tmpdir))

tests/unit/test_self_check_outdated.py:53: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <MagicMock name='SelfCheckState' id='133415676229152'>, args = ()
kwargs = {'cache_dir': '/tmp/pytest-of-builduser/pytest-0/test_pip_self_version_check_ca0'}
msg = "Expected 'SelfCheckState' to be called once. Called 0 times."

    def assert_called_once_with(self, /, *args, **kwargs):
        """assert that the mock was called exactly once and that that call was
        with the specified arguments."""
        if not self.call_count == 1:
            msg = ("Expected '%s' to be called once. Called %s times.%s"
                   % (self._mock_name or 'mock',
                      self.call_count,
                      self._calls_repr()))
>           raise AssertionError(msg)
E           AssertionError: Expected 'SelfCheckState' to be called once. Called 0 times.

/usr/lib/python3.13/unittest/mock.py:988: AssertionError

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[notatallshaw]

Do you think this behavior is incorrect?

Reading over this I would suggest updating the test to match the new behavior. But let us know if you think otherwise.

[christian-heusel]

I think the new behavior makes sense and would like to keep that, so I'd say either fixing the test to match the new behavior or skip it with the test framework in case of EXTERNALLY-MANAGED is the way to go. 😊

[ichard26]

Sorry about the spurious error! I've updated the test to patch out the check as we already have a test for "is the self-check disabled when the environment is externally-managed." I'd like to keep this test, which tests the self-check implementation, working in all situations.

[ichard26]

Also, while we're here. Hi @christian-heusel, good to meet someone from Arch! 👋

Would you be a good point of contact for Python on Arch Linux? This wouldn't be a formal designation or anything. It's just that we (the pip project) may make some changes that have consequences for our redistributors. We'd like to reach out before making them to avoid churn. For example, #13010 was a change where we reached out to our redistributors, but we had no representation from Arch¹

Footnotes

1. That's actually not true, but our current Arch contact is a bit busy/unavailable. ↩

[christian-heusel]

Hey @ichard26, also glad to meet y'all! 👋🏻

Yes me and @dvzrv are currently maintaining the pip package in Arch Linux, so if you're requiring input from any of us you can just contact / tag us in the issue or PR. If wished for we can also try to get input from other python packaging folks within Arch Linux that (heavily) use pip in their packages 😊

[ichard26]

Great, thank you! I'll try to remember your usernames. (Last time I copied the mentions from an old issue, I'll probably do that again whenever the time comes up.)