[pip 25.1] assert req.source_dir fails with the legacy resolver enabled

[ramannanda9]

Description

Seeing build failures because of this function, my guess is this function was supposed to check whether the stuff needs to be built, but the commit 5b20593
is causing assertion failures, we will need to pin pip till this is resolved.

Expected behavior

The assertion should not be there, a check was fine.

pip version

25.1

Python version

3.9

OS

Al2023

How to Reproduce

Try installing certifi,

I will add more details soon.

Output

File "/usr/local/lib/python3.9/site-packages/pip/_internal
/wheel_builder.py", line 53, in _should_build
2025-04-27 12:03:18,230:INFO:__main__:deploy_model: 24.64
assert req.source_dir

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[ichard26]

We can't do anything unless we have reproduction steps. Please do update your issue with reproduction information.

Installing certifi from source on Python 3.9 does result in the bdist_wheel deprecation warning, but it builds just fine.

[andreaschiappacasse]

Hi everyone, currently don't have time to fully reproduce the bug, but I am experiencing the same error while installing a custom package as well in our environment.

Pinned requirements used to build just fine with pip 25.0.1, but after our build environment migrated to pip 25.1 we started experiencing build failures at the same line mentioned by @ramannanda9 (assertion error while loonking for source_dir).

[ichard26]

Given that there is only two reports of this bug, there still isn't anything we can do. We could revert the commit as it was simply a refactoring change, but I don't want to do that unless we know why it's broken and the severity of the bug (which for all we can tell is rather limited).

If anyone else is affected by this crash, please send in a minimum reproduction example. We cannot do anything otherwise.

[pfmoore]

One particular thing that could shed light on this issue - are the people experiencing this bug just using pip as a command line tool, or are they using code that imports pip in some way? Because we changed the test to an assert because pip should never be passing a requirement without a source_dir to _should_build. If it is, we need a reproducer to find out where that is occurring (and fix that, rather than just remove the check and accept that we don't know what pip is doing internally 🙁).

If the issue is triggered by importing pip and using internals somehow, then such usage is not supported, as people will be aware. We may still be able to help, but not without understanding what people are trying to do (and of course, as it's unsupported usage, there are no guarantees).

Either way, we can do nothing without a description of how to trigger the issue.

[sbidoul]

I'd be in favor of leaving the assert in place until we receive a reproducer, which I'll be happy to investigate rapidly.

The reason I made this an assert is that while I thought it could never happen, I had doubts, and it is critical to understand in which circumstances this req.source_dir can be falsy, because _should_build will be changed to return always True soon (then be removed), and we need to clarify that edge case beforehand.

[Rahlir]

I have stumbled upon this issue as well. Simple way to reproduce it:

1. Use fresh virtualenv and python 3.11.9
2. Upgrade pip with pip install --upgrade pip
3. Running pip --version returns pip 25.1
4. Run pip install aiohttp[speedups] == 3.11.16 and you will get AssertionError on assert req.source_dir.

[sbidoul]

@Rahlir thanks! I tried this but it does not reproduce:

#!/bin/bash
set -eaux
venv=$(mktemp -d)
python3.9 -m venv $venv
$venv/bin/pip install --upgrade pip
$venv/bin/pip install aiohttp[speedups]==3.11.16

Can you provide additional information? Maybe pip config debug.

Edit: same with python 3.11.12, and 3.11.9.

[avengersassemble]

Facing the same issue, @sbidoul

Attaching Dockerfile and requirements.txt to reproduce this issue.

requirements.txt

Dockerfile.txt

[notatallshaw]

@avengersassemble I'm not near a computer right now but can you please check without --Use-deprecated=legacy-resolver

[Rahlir]

@Rahlir thanks! I tried this but it does not reproduce:

#!/bin/bash
set -eaux
venv=$(mktemp -d)
python3.9 -m venv $venv
$venv/bin/pip install --upgrade pip
$venv/bin/pip install aiohttp[speedups]==3.11.16

Can you provide additional information? Maybe pip config debug.

Edit: same with python 3.11.12, and 3.11.9.

Ups, you are right, this is due to the --use-deprecated=legacy-resolver, forgot that that was included in our company's default pip.conf. So, you can also reproduce the issue with my example by running the last command with --use-deprecated=legacy-resolver. So, my guess is that the Docker example has the assertion error also due to the legacy-resolver (I am unable to run it right now).

Is there a reason this fails with the legacy-resolver? I guess I will remove it from our config for now (not sure what was the original reason that we used it).

[ramannanda9]

Yep it has to do with deprecated resolver flag, something not easy to switch out.

bash-5.2# pip install --use-deprecated=legacy-resolver "certifi"
Looking in indexes: https://artifactory.vertigo.stitchfix.com/artifactory/api/pypi/stitchpy/simple
Requirement already satisfied: certifi in /usr/local/lib/python3.11/site-packages (2025.4.26)
ERROR: Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/cli/base_command.py", line 105, in _run_wrapper
    status = _inner_run()
             ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/cli/base_command.py", line 96, in _inner_run
    return self.run(options, args)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/cli/req_command.py", line 68, in wrapper
    return func(self, options, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/commands/install.py", line 421, in run
    reqs_to_build = [
                    ^
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/commands/install.py", line 424, in <listcomp>
    if should_build_for_install_command(r)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/wheel_builder.py", line 65, in should_build_for_install_command
    return _should_build(req)
           ^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pip/_internal/wheel_builder.py", line 53, in _should_build
    assert req.source_dir
           ^^^^^^^^^^^^^^
AssertionError

[avengersassemble]

Yep, the build fails with the requirements mentioned in my file without legacy resolver. So, I am not able to reproduce the same issue.

[notatallshaw]

Is there a reason this fails with the legacy-resolver? I guess I will remove it from our config for now (not sure what was the original reason that we used it).

When the current resolver was made default in 20.3 there were a lot of users who had difficulty using it for a variety of reasons. At this point though I hope only a very small number of users actually have a use case that requires the legacy resolver.

[ichard26]

The answer of why it fails with the legacy resolver is that we don't really support the legacy resolver anymore. We have some tests, but we haven't added any legacy resolver tests since well.. it was NOT legacy. We've kept it around because its removal would've been quite disruptive. I'm not sure how disruptive it would be today, but in general, it hasn't been a burden either so it's been left alone.

[edmorley]

In the pip install examples above that are using --use-deprecated=legacy-resolver I don't see any deprecation warnings from pip about the legacy resolver - and searching this repo now I can't find any either.

Would it be worth adding some deprecation warnings to the log output in pip 25.2 as a first small step towards https://github.com/pypa/pip/milestone/47 ?

At the very least, such deprecation warnings would make issues like this one easier for maintainers to debug (particularly for cases where the user has the legacy resolver unknowingly enabled via global config or env var).

[pfmoore]

The idea is that warnings aren't needed, because the requirement to explicitly opt into the deprecated behaviour is enough. However, I feel that we might have let people get complacent by not making any progress on removal - it's been nearly 5 years now 🙁

I'm -1 on adding warnings to the log output, but I could see some value to adding a warning message to the normal output. Doing so would almost certainly break some people's workflows, but I don't see how we can move towards removal without starting to be more aggressive about breaking things.

As far as this particular issue is concerned, do we want to say that people affected need to pin to 25.0? Does the problem affect all uses of the legacy resolver, or just a small fraction of them? We could just revert the assertion, but surely at some point we need to stop keeping the legacy resolver alive...

[edmorley]

I'm -1 on adding warnings to the log output, but I could see some value to adding a warning message to the normal output.

By log output, I mean the normal output (I didn't realise pip even wrote logs to a file for successful builds?).

[pfmoore]

Would it be worth adding some deprecation warnings to the log output in pip 25.2 as a first small step towards https://github.com/pypa/pip/milestone/47 ?

I think the best way forward on that milestone is probably to ask if the various issues on there still exist (specifically, are people still using --use-deprecated=legacy-resolver in their workflows to work around them)? If we can determine that the known blockers are no longer relevant, the next step is probably just to make a public statement of when we intend to remove the legacy resolver for good. At that point, we could issue a deprecation warning when people use the --use-deprecated=legacy-resolver option.

I'm not sure we should issue a warning before we can state a firm removal date.

By log output, I mean the normal output

Ah, OK. I assumed you meant the debug output or something like that which wasn't visible by default.

[notatallshaw]

FWIW I'm going to take a quick look tonight and see if there's a simple fix for this specific issue. Deciding when to remove the legacy resolver is probably a separate issue (and there probably is a years old issue knocking around for exactly that).

[ramannanda9]

I would say certain times the legacy resolver was kept in place because you want to force install certain requirements at the beginning, the new resolver would just error out in trying to find compatible requirements, legacy resolver would have just warned, if "incompatible" stuff was there. It's still there in many codebases..

[pfmoore]

@ramannanda9 Unfortunately, that's not a good reason for pip to retain the legacy resolver. Being able to install a set of requirements that are incompatible was a bug in the legacy resolver, and supporting people who rely on that bug has never been a goal.

If projects want to continue using that capability, then at some point they will have to pin their version of pip.

[notatallshaw]

If projects want to continue using that capability, then at some point they will have to pin their version of pi

There are two other options for users with this use case:

• Write a script that installs each requirement one at a time. While pip is consistent on a single install command it does not try to make the install consistent with your existing environment and so installing one at a time is very similar to the legacy resolver (though be aware this behavior may change in the future).
• Use a different Python package installer, like uv or pdm, which have features to override requirements or provide your own dependency metadata for individual packages.

[notatallshaw]

I have a simple reproducer:

1. In a clean Python 3.11 venv with pip 25.1+
2. pip install setuptools
3. pip install --use-deprecated=legacy-resolver "spacy==3.8.4"

The issue appears to be triggered by already installed packages, I suspect in the legacy resolver's _check_skip_installed skips over setting properties that should_build in the wheel builder needs.

[sbidoul]

I propose a fix in #13363