webcomics
uv fails to install dependencies with wine
The following minimal project cannot be build with uv. It fails resolve dependencies and create a uv.lock file when build with wine
Project structure
├── Dockerfile
├── pyproject.toml
├── README.md
└── src
└── wine_error
├── __init__.py
└── main.py
With the following files
Dockerfile:
FROM tobix/pywine:3.13
WORKDIR /app
RUN wine pip install uv
COPY . .
RUN wine uv sync -v
RUN wine cmd.exe /c dir. # just to show, that uv.lock file is missing
CMD ["wine","uv", "run", "--no-sync", "python", "src/wine_error/main.py"]
main.py:
import httpx
r = httpx.get("https://example.com")
print(r.text)
pyproject.toml:
[project]
name = "wine-error"
version = "0.1.0"
description = ""
authors = [{ name = "test user", email = "[email protected]" }]
requires-python = ">=3.9,<3.14"
readme = "README.md"
dependencies = [
"httpx>=0.28.1",
]
[dependency-groups]
dev = ["pyinstaller"]
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
When this project is build and run with
docker build . -t wine_error --platform=linux/amd64
docker run --rm -t -i --platform=linux/amd64 wine_error
it will fail with
rosetta error: invalid gdt selector index 5
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
Traceback (most recent call last):
File "Z:\app\src\wine_error\main.py", line 1, in <module>
import httpx
ModuleNotFoundError: No module named 'httpx'
The reason seems to be that during docker build uv somehow fails silently and is not creating a virtual environment and a uv.lock file. You can see in the following output that in the end a uv.lock file does not exist, because uv simply does not seem to finish its work. It fails silently to create a virtual environment with the httpx dependency installed. Then running the docker container it will therefor fail to find the necessary dependency.
#7 [3/6] RUN wine pip install uv
#7 0.592 rosetta error: invalid gdt selector index 5
#7 0.592 error: XDG_RUNTIME_DIR is invalid or not set in the environment.
#7 4.597 Collecting uv
#7 4.706 Downloading uv-0.8.18-py3-none-win_amd64.whl.metadata (12 kB)
#7 4.770 Downloading uv-0.8.18-py3-none-win_amd64.whl (21.0 MB)
#7 6.521 ---------------------------------------- 21.0/21.0 MB 12.2 MB/s 0:00:01
#7 6.628 Installing collected packages: uv
#7 6.937 Successfully installed uv-0.8.18
#7 DONE 7.2s
#8 [4/6] COPY . .
#8 DONE 0.1s
#9 [5/6] RUN wine uv sync -v
#9 1.089 DEBUG uv 0.8.18 (c4c47814a 2025-09-17)
#9 1.101 DEBUG Found project root: `Z:\app`
#9 1.103 DEBUG No workspace root found, using project root
#9 1.106 DEBUG Acquired lock for `Z:\app`
#9 1.110 DEBUG No Python version file found in workspace: Z:\app
#9 1.111 DEBUG Using Python request `>=3.9, <3.14` from `requires-python` metadata
#9 1.111 DEBUG Checking for Python environment at: `.venv`
#9 1.113 DEBUG Searching for Python >=3.9, <3.14 in managed installations, search path, or registry
#9 1.114 DEBUG Searching for managed installations at `C:\users\root\AppData\Roaming\uv\python`
#9 1.659 error: XDG_RUNTIME_DIR is invalid or not set in the environment.
#9 1.891 DEBUG Found `cpython-3.13.7-windows-x86_64-none` at `C:Python\python.exe` (first executable in the search path)
#9 1.891 Using CPython 3.13.7 interpreter at: C:\Python\python.exe
#9 1.894 Creating virtual environment at: .venv
#9 1.895 DEBUG Using base executable for virtual environment: C:\Python\python.exe
#9 1.907 DEBUG Released lock at `C:\users\root\AppData\Local\Temp\uv-030b7ed6fbcf7226.lock`
#9 1.908 DEBUG Acquired lock for `.venv`
#9 1.916 DEBUG Using request timeout of 30s
#9 1.931 DEBUG Found static `pyproject.toml` for: wine-error @ file:///Z:/app
#9 1.931 DEBUG No workspace root found, using project root
#9 1.946 DEBUG Solving with installed Python version: 3.13.7
#9 1.946 DEBUG Solving with target Python version: >=3.9, <3.14
#9 1.956 DEBUG Adding direct dependency: wine-error*
#9 1.957 DEBUG Adding direct dependency: wine-error:dev*
#9 1.960 DEBUG Searching for a compatible version of wine-error @ file:///Z:/app (*)
#9 1.962 DEBUG Adding direct dependency: httpx>=0.28.1
#9 1.964 DEBUG Searching for a compatible version of wine-error @ file:///Z:/app (*)
#9 1.964 DEBUG Adding direct dependency: wine-error:dev==0.1.0
#9 1.965 DEBUG Acquired lock for `C:\users\root\AppData\Local\uv\cache\simple-v18\pypi\httpx.lock`
#9 1.966 DEBUG Searching for a compatible version of wine-error @ file:///Z:/app (==0.1.0)
#9 1.966 DEBUG Adding direct dependency: pyinstaller*
#9 1.969 DEBUG No cache entry for: https://pypi.org/simple/httpx/
#9 1.976 DEBUG Acquired lock for `C:\users\root\AppData\Local\uv\cache\simple-v18\pypi\pyinstaller.lock`
#9 1.976 DEBUG No cache entry for: https://pypi.org/simple/pyinstaller/
#9 2.049 rosetta error: invalid gdt selector index 5
#9 2.049
#9 DONE 2.1s
#10 [6/6] RUN wine cmd.exe /c dir
#10 1.092 Volume in drive Z has no label.
#10 1.093 Volume Serial Number is 5a00-0000
#10 1.093
#10 1.096 Directory of Z:\app
#10 1.096
#10 1.096 09/19/2025 04:29 PM <DIR> .
#10 1.096 09/19/2025 04:29 PM <DIR> ..
#10 1.097 09/19/2025 04:29 PM <DIR> .venv
#10 1.097 09/16/2025 08:53 AM 197 build-win.spec
#10 1.097 09/19/2025 04:28 PM 235 Dockerfile
#10 1.098 09/19/2025 04:06 PM 344 pyproject.toml
#10 1.098 09/16/2025 07:32 AM 2,430 README.md
#10 1.098 09/16/2025 08:24 AM <DIR> src
#10 1.098 4 files 3,206 bytes
#10 1.098 4 directories 482,602,713,088 bytes free
#10 1.099
#10 DONE 1.1s
Is this a uv bug? Or am I using uv wrongly in connection with wine? poetry on the other side seems to work fine with pywine.
rosetta error: invalid gdt selector index 5
Is this on an ARM Mac? Does it happen on real x86_64 hardware?
Since I don't have any x86_64 hardware I created a test VM with x86 architecture on Google Cloud. I ran the docker commands and they worked as expected.
So it seems this is really an issue caused by the rosetta emulation on my Mac M3. I was just confused, because it doesn't happen, when trying to use poetry instead of uv. It seems uv uses machine instructions which cause problems with rosetta. The strange thing is, it doesn't crash the build process, it simply does not complete the uv sync task and continues with the next docker run command.
I mean, uv is written in Rust, so there is that...
I have no idea how Rosetta 2 works in Docker Desktop(?) on Mac... From what I have found in Apple Developer documentation, I would assume that Docker runs an ARM64 Linux VM, which has a special Linux build of Rosetta 2 registered as a binfmt_misc handler, so containers running in that VM can execute x86_64 binaries automagically... That sounds like a less-well-tested codepath then the "main" Rosetta 2 for desktop applications... So maybe the "wrong" return code for crashed Rosetta 2 processes is just another Rosetta 2 bug?
Since Rosetta 2 has been soft-deprecated, I was pondering providing an ARM64 wine-docker container (with some funky "hack" like https://github.com/AndreRH/hangover) to help users "trapped" on ARM64 hardware... (I mean I started this set of containers for users "trapped" on non-Windows-systems, so this would be kind-of "in scope" 😆) - My problem is that I don't have any powerful ARM64 hardware myself (My Pi 4 server only has 2GB of RAM and is occupied with other stuff)...
I now also tried it using Orbstack. Orbstack does not use the Linux VM like Docker Desktop does. It also allows to deactivate Rosetta and use some other slower fallback emulation: https://docs.orbstack.dev/settings#use-rosetta-to-run-intel-code
However with Rosetta turned on, the results with Orbstack are exactly the same as with Docker Desktop. When I turn off rosetta emulation, already the building of the docker container will fail:
❯ docker build . -t wine_error --platform=linux/amd64 --no-cache
[+] Building 0.9s (7/10) docker:orbstack
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 274B 0.0s
=> [internal] load metadata for docker.io/tobix/pywine:3.13 0.2s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 77B 0.0s
=> [1/6] FROM docker.io/tobix/pywine:3.13@sha256:a2500460a7dae0aadd0524648f1cac1f35bd57c6b50be034747217583a2db471 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 35.14kB 0.0s
=> CACHED [2/6] WORKDIR /app 0.0s
=> ERROR [3/6] RUN wine pip install uv 0.6s
------
> [3/6] RUN wine pip install uv:
0.548 Application could not be started, or no application associated with the specified file.
0.548 ShellExecuteEx failed:
------
Dockerfile:5
--------------------
3 | WORKDIR /app
4 |
5 | >>> RUN wine pip install uv
6 |
7 | COPY . .
--------------------
ERROR: failed to build: failed to solve: process "/bin/sh -c wine pip install uv" did not complete successfully: exit code: 1
View build details: docker-desktop://dashboard/build/orbstack/orbstack/9vmjz2w6aakkwd9wso9o6tary
So it seems Rosetta is still the best way to go for emulating x86 architecture on ARM Macs. However for running wine reliably it is not good enough.
If you want to try with a different x86_64 emulator, I made a test image with Hangover (which can use FEX or Box64): docker.io/tobix/wine:test-arm64 - There is a current x86_64 uv in the image as /uv.exe, so you can probably start with RUN wine /uv sync -v
Still not sure if I want to provide this as a standard feature of my wine/pywine images...