fix(setuptools): wrapper path compatibility with scikit-build (classic)

[henryiii]

I tried swapping this out on taichi-dev/taichi, and got differing wheels. I had Kimi-K2.6 prepare a report of the differences, then fed that into GPT 5.4. I made this wrapper-only. I was using #1285 as well (that's why I picked that repo).

I set up a docker build for Taichi, since it doesn't support modern LLVM or even ARM Linux.

Dockerfile

# syntax=docker/dockerfile:1

FROM ubuntu:22.04

# Prevent interactive prompts during apt install
ENV DEBIAN_FRONTEND=noninteractive

# Install system dependencies
RUN apt-get update && apt-get install -y \
    build-essential curl git python3-dev \
    llvm clang zlib1g-dev libzstd-dev \
    libx11-dev libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev \
    mesa-common-dev \
    && rm -rf /var/lib/apt/lists/*

# Install uv (astral package manager)
RUN curl -LsSf https://astral.sh/uv/install.sh | sh
ENV PATH="/root/.local/bin:${PATH}"

# Create workdir and clone taichi
# This will be overwritten if you mount a local directory to /root/taichi
WORKDIR /root/taichi

# Default shell for interactive use
CMD ["/bin/bash"]

I even got a docker-compose, since I asked Kimi-K2.6 to make sure Ollama could be reached (didn't use it yet):

docker-compose.yml:

services:
  taichi-dev:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: taichi-dev
    # Keep the container running interactively
    stdin_open: true
    tty: true
    # Mount your local project directory for live edits
    volumes:
      - ./taichi:/root/taichi/tachi
    # Connect to Ollama running on the host machine
    # 'host.docker.internal' works on Docker Desktop (Mac/Windows).
    # On Linux, you may need to use 'host' network mode or the host's LAN IP.
    extra_hosts:
      - "host.docker.internal:host-gateway"
    # Pass through your local environment variable
    environment:
      # Point to the host Ollama endpoint
      - OLLAMA_HOST=http://host.docker.internal:11434
    # Use host networking on Linux if host.docker.internal is unavailable
    # network_mode: host

README.md

Taichi Development Container

A Docker setup for working interactively on the Taichi project.

What's included

• Ubuntu 22.04
• Build essentials (build-essential, curl, llvm, git)
• uv Python environment manager
• Pre-cloned Taichi repository with initialized submodules
• Core dependencies

Prerequisites

• Docker
• (Optional) Docker Compose

Quick Start

Using Docker Compose

1. Build and start the container:

   docker compose up --build

2. If you want to run the container in the background and drop into a shell on demand:

   docker compose up --build -d
   docker exec -it taichi-dev bash

Using Docker directly

# Build the image
docker build -t taichi-dev .

# Run interactively
docker run --rm -it \
  -v "$(pwd)/taichi:/root/taichi" \
  -e EXAMPLE_VARIABLE="your_value" \
  -e OLLAMA_HOST="http://host.docker.internal:11434" \
  taichi-dev

Connecting to Ollama

The container is configured to reach Ollama running on your host machine.

• macOS / Windows: Use http://host.docker.internal:11434 (automatically set via OLLAMA_HOST).
• Linux: If host.docker.internal does not resolve, uncomment the network_mode: host line in docker-compose.yml and use http://localhost:11434 instead.

Environment Variables

Variable	Description
OLLAMA_HOST	Points to the Ollama API endpoint on your host.

Build

Run:

cd taichi
uv venv --clear
CMAKE_POLICY_VERSION_MINIMUM=3.5 CMAKE_BUILD_PARALLEL_LEVEL=8 CXX=clang++ CC=clang uv pip install -v .

You need DOCKER_DEFAULT_PLATFORM=linux/amd64 docker compose up --build -d to get Intel. You need to check out Taichi in this directory, and it will be mounted. venv does show up on host too, unfortunately. Use uv build --wheel to build wheels for comparison.

🤖 Assisted-by: Copilot:GPT-5.4

[henryiii]

And here's the report:

🤖 report

TL;DR

The SDists are identical, but the wheels have very different internal layouts.

---

SDist (*.tar.gz) — Identical

diff shows zero differences between dist_skb/taichi-1.8.0.tar.gz and dist_skbc/taichi-1.8.0.tar.gz. Both contain:

• Build metadata (setup.py, pyproject.toml, MANIFEST.in, PKG-INFO)
• Source Python package under taichi-1.8.0/python/taichi/...
• Pre-built CMake install tree under taichi-1.8.0/_skbuild/linux-x86_64-3.10/cmake-install/...

---

Wheel (*.whl) — Structurally Different

The files inside the wheels are mostly the same set of files, but placed in completely different locations:

dist_skb/*.whl (scikit-build)

What	Where in the zip
Data files (include/, lib/cmake/, share/)	taichi-1.8.0.data/data/...
Compiled Python extension (taichi_python*.so)	taichi/_lib/core/...
C API library (libtaichi_c_api.so)	taichi/_lib/c_api/lib/...
Runtime bitcode (.bc files)	taichi/_lib/runtime/...
Pure Python sources	taichi/...

dist_skbc/*.whl (scikit-build-core)

What	Where in the zip
Data files (include/, lib/cmake/, share/)	At the root of the zip (include/..., lib/..., share/...)
Compiled Python extension (taichi_python*.so)	python/taichi/_lib/core/...
C API library (libtaichi_c_api.so)	python/taichi/_lib/c_api/...
Runtime bitcode (.bc files)	python/taichi/_lib/runtime/...
Pure Python sources	taichi/... (but missing the compiled .so/.bc subdirectories)

What this means

The dist_skb wheel is correctly structured:

• Data files are inside .data/data/ so pip installs them to proper system-ish locations (e.g. sys.prefix/include/).
• Compiled extensions/libraries live inside the taichi/ package directory, so import taichi can find them at runtime.

The dist_skbc wheel appears broken:

• Data files at the zip root will land in site-packages/include/ and site-packages/lib/, not in sys.prefix/.
• Compiled extensions under python/taichi/_lib/... will be installed to site-packages/python/taichi/_lib/..., not site-packages/taichi/_lib/.... The pure-Python taichi package in the wheel does not contain those .so/.bc files, so Taichi won't be able to load them at runtime.