pip installs a wheel even if --no-binary is given

[paugier]

Description

I like to install mpi4py with a new build (without using a wheel already locally built). I try to use --no-binary mpi4py but surprisingly a wheel is used.

(venv-mpi4py) [egi2153] augier@login2:~$ CC=mpicc pip install mpi4py --no-binary mpi4py
Looking in indexes: https://gorgone.cines.fr//root/pypi/+simple/
Collecting mpi4py
  Using cached mpi4py-4.0.0-cp311-cp311-linux_x86_64.whl
Installing collected packages: mpi4py
Successfully installed mpi4py-4.0.0

Note that there is a pip config file:

$ cat /etc/pip.conf
[global]
index-url=https://gorgone.cines.fr//root/pypi/+simple/
trusted-host=gorgone.cines.fr

Expected behavior

mpi4py should be compiled from source when --no-binary mpi4py is given.

See the help message:

  --no-binary <format_control>
                              Do not use binary packages. [...]

pip version

pip 24.2

Python version

3.11

OS

Linux

How to Reproduce

python -m venv venv-mpi4py
.  ~/venv-mpi4py/bin/activate
pip install --upgrade pip
pip install mpi4py --no-binary mpi4py

Output

$ pip install mpi4py --no-binary mpi4py
Looking in indexes: https://gorgone.cines.fr//root/pypi/+simple/
Collecting mpi4py
  Using cached mpi4py-4.0.0-cp311-cp311-linux_x86_64.whl
Installing collected packages: mpi4py
Successfully installed mpi4py-4.0.0

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

If we built the wheel previously, and the source is identical, we'll re-use the cached wheel rather than spending the time doing a build which will give the same result. Even with --no-binary, as we're in principle still using the sdist. Could that be the case here?

[paugier]

Yes, it is exactly the case and the issue.

IMHO, it is for most packages with extensions the wrong behavior. There can be different reasons so that the same source would give different wheels, for example different compilers, different library implementations (like for MPI) or different build options.

If the user specifically states --no-binary mpi4py, pip should trust the user and rebuild from source.

[eli-schwartz]

I personally would find it fairly surprising to pass an option that says "do not install binary packages" and have it be interpreted as "Do not use manylinux wheels from PyPI, but do use binary packages from elsewhere".

That being said, there's overall two reasons for no-binary:

• as a form of cache-busting, because you want to reconfigure the mechanism the sdist uses for building and try again
• distrust of "other people's binaries" / wanting to bootstrap the ecosystem from source for purity reasons

My gut feeling is that the latter group doesn't mind ignoring caches. They've already committed to the possibility of needing to perform potentially lengthy builds by passing no-binary at all, so trying to spare them the extra work of recompiling a wheel they previously successfully created isn't something they needed to happen -- and if it was successfully built once, it will most likely successfully build again. :)

On the other hand, the former group needs to have some way of achieving their goals, which appear to currently be entirely impossible? It seems like the safe bet is to make both cases work, even if that means making one case work less optimally. (Or I suppose add a new command-line option, but this doesn't seem appetizing.)

[notatallshaw]

IMO this is a bug, the sdist should be rebuilt unless there is an explicit option pip could provide to build or not rebuild sdists.

Do maintainers disagree? Would a PR be accepted by someone willing to submit a sufficently high quality PR? (e.g. include explicit tests). I'm not volunteering (at least yet), just trying to triage this issue.

[pfmoore]

I'm uncertain. I don't buy the argument that it's wrong to use a cached build of a sdist. Maybe we should just improve the message - rather than saying "Using cached mpi4py-4.0.0-cp311-cp311-linux_x86_64.whl" we could say "Using mpi4py-4.0.0.tar.gz (skipping rebuild as we can use the previously cached result saved as mpi4py-4.0.0-cp311-cp311-linux_x86_64.whl)".

If the only use case is cache busting, maybe what we need is finer grained options than --no-cache-dir? Maybe all we need is --no-wheel-cache?

But having said this, I'm not going to block a sufficiently high quality PR. I just don't think it's necessarily the right direction to take.

[notatallshaw]

Maybe all we need is --no-wheel-cache?

Or maybe --no-built-cache <package>? Using the same syntax as --no-binary and --only-binary, as this is just about sdists being built, a package which is a wheel candidate should still use the wheel cache right?

Anyway, seem like this can be solved multiple ways, I've updated this to "awaiting PR".

[sbidoul]

I'm -1 on changing the behaviour of --no-binary with regards to using cached locally built wheels. The current approach is useful and, while it does not fit all use cases, I think it is a good default.

We can refine the caching keys, though (see for instance #11164).

I'm also open to some sort of per-distribution-name cache control. If this becomes the tracking issue for that, and that is what is expected in the awaited PR, we should consider changing the issue title.

As workaround in the current state of affairs, would pip cache purge <package> ; pip install <package> --no-binary <package> work for you?

[sbidoul]

I'm removing the bug label, as things are working as designed.