uv refuses to use a wheel that is definitely built using a matching python implementation

[kvelicka]

I'm trying to pre-build some wheels for a Pyston based build pipeline. I've realised that using uv pip install appears to ignore my pre-built wheels. DEBUG/TRACE level logging doesn't seem to provide enough information as to why the wheel I built was unsuitable.

I managed to get the repro down to a fairly minimal Dockerfile, which will hopefully make this bug not too onerous to reproduce. It might be useful to run the Dockerfile using DOCKER_BUILDKIT=0 docker build . as doing it that way doesn't swallow logs/output (e.g. output of ls $HOME/wheels). In the example I'm packaging gevent but the issue isn't package specific AFAICT.

On my machine the last command fails with

  × No solution found when resolving dependencies:
  ╰─▶ Because gevent==24.2.1 is unusable because no wheels are available with
      a matching Python implementation and you require gevent==24.2.1, we can
      conclude that the requirements are unsatisfiable.

FROM ubuntu:22.04

RUN apt update && apt install -qqy git curl build-essential libffi-dev

ENV HOME /root

ENV PYENV_ROOT $HOME/.pyenv
RUN git clone https://github.com/pyenv/pyenv.git $PYENV_ROOT
ARG PYTHON=pyston-2.3.5
RUN $PYENV_ROOT/bin/pyenv install $PYTHON
ENV PATH $PYENV_ROOT/versions/$PYTHON/bin:$PATH

RUN python -m pip install uv==0.1.32

RUN uv venv --seed /root/.venv
# Poor man's `activate` - can't just `activate` in a docker image
ENV PATH="/root/.venv/bin:$PATH"

RUN mkdir $HOME/wheels
WORKDIR $HOME/wheels

RUN pip wheel --no-deps gevent==24.2.1

WORKDIR $HOME

RUN ls $HOME/wheels

RUN uv pip install --offline --find-links $HOME/wheels/ -v gevent==24.2.1

# alternative repro
# RUN uv pip install --only-binary ':all:' --find-links $HOME/wheels/ -v gevent==24.2.1

[charliermarsh]

Thanks for the clear repro. I was able to reproduce but haven't yet dug into what's happening.

[kvelicka]

Actually it's worth mentioning #1681 here, as the repro above is a reduced example of how we use the pip wheel command.

[charliermarsh]

(Still on my list to look into this.)

[charliermarsh]

The problem is that sys.implementation.version is return 3.8, when it should be returning 2.3, I guess? So we're looking for a wheel like pyston38-pyston_38.

[charliermarsh]

Is this a Pyston bug? I'm confused.

[charliermarsh]

version is a named tuple, in the same format as sys.version_info. It represents the version of the Python implementation. This has a distinct meaning from the specific version of the Python language to which the currently running interpreter conforms, which sys.version_info represents. For example, for PyPy 1.8 sys.implementation.version might be sys.version_info(1, 8, 0, 'final', 0), whereas sys.version_info would be sys.version_info(2, 7, 2, 'final', 0). For CPython they are the same value, since it is the reference implementation.

[charliermarsh]

But in the above, I see sys.version_info(major=3, minor=8, micro=12, releaselevel='final', serial=0). So I don't see how I would get pyston_23, where is it exposed? 🤔

[charliermarsh]

Wow, I guess you're supposed to do something like this? https://github.com/isabella232/tox-gh/blob/b3f9ac0150f30be765ada0dcde8b4eb18f7373a6/src/tox_gh/plugin.py#L35

I got there from reading pyston/pyston#39.

[charliermarsh]

Yeah, that does return sys.version_info(major=2, minor=3, micro=5, releaselevel='final', serial=0). Interesting. Why on Earth don't they return that from sys.implementation.version?

[kvelicka]

Thanks a lot of looking into this. I hoped that this was something about it being not-cpython rather than a Pyston-specific quirk but sounds like latter is the case. Hopefully you can find some simple fix/workaround for this but if that's looking unlikely it's probably not the end of the word - I expect uv's Pyston userbase to be a vanishingly small percentage of all users so no hard feelings if this ends up as wontfix!

[charliermarsh]

Hmm yeah, I think I'm gonna close this as wontfix. I changed our logic to return the pyston_version_info when present, but the wheels still aren't quite working. I'm confused because the wheel tag is pyston38-pyston_23_aarch64_linux_gnu-linux_aarch64, but I feel like it should be... pyston38_pyston_23-aarch64_linux_gnu-linux_aarch64, since we split on -? I'm sure I'm wrong, but it's hard to justify investing deeply in it -- sorry about that!

[charliermarsh]

I'm realizing that I misread the tag. It's pyston38-pyston_23_aarch64_linux_gnu-linux_aarch64, which is (pyston38, pyston_23_aarch64_linux_gnu, linux_aarch64).

[kvelicka]

Does that mean that this is more viable than previously anticipated or not really? Thanks!