| name | compat-matrix | ||||
|---|---|---|---|---|---|
| description | Cross-OS / cross-Minecraft-version build-and-render compatibility harness for The-Minecraft-Overviewer. Builds the c_overviewer C extension against each environment's numpy and Pillow, then renders a set of test worlds against their matching-version Minecraft client jars and reports a pass/fail matrix. | ||||
| when_to_use | Use before merging changes that touch the C extension, setup.py, dependency pins, or version-specific texture/world handling. Run it to confirm Overviewer still builds and renders on Ubuntu 22.04 / 24.04 / 26.04 (numpy/Pillow from apt) and Windows 11 with Python >= 3.12 (numpy/Pillow from pip), across the supported Minecraft world formats. | ||||
| entrypoints |
|
||||
| inputs |
|
||||
| outputs |
|
||||
| requires |
|
||||
| network | yes — fetches matching Pillow sdist C headers from PyPI at build time | ||||
| safety | read-only on real saves; worlds are copied to a scratch dir before rendering |
This folder verifies that Overviewer builds and renders across the operating systems and Minecraft versions we support, using each platform's own numpy and Pillow (apt-provided on Ubuntu, pip on Windows). It exists because several incompatibilities only appear on specific combinations — e.g. numpy 2.x build flags on gcc, the Pillow 12 C-API change, and Minecraft 26.2 texture relocations.
Run the whole matrix from the repo root on the Windows host (needs Docker Desktop running and the Minecraft client jars installed):
python test/compat/run_matrix.pyThat stages the test worlds to a scratch dir, then runs four legs — Windows native plus Ubuntu 22.04 / 24.04 / 26.04 containers — building the C extension and rendering all three worlds in each. It prints a matrix like:
scenario python numpy result per-world
Windows-native 3.14.5 2.5.0 PASS Derek-Single=ok Tester=ok GiveEr26_2=ok
Ubuntu 22.04 3.10.12 1.21.5 PASS Derek-Single=ok Tester=ok GiveEr26_2=ok
Ubuntu 24.04 3.12.3 1.26.4 PASS Derek-Single=ok Tester=ok GiveEr26_2=ok
Ubuntu 26.04 3.14.4 2.3.5 PASS Derek-Single=ok Tester=ok GiveEr26_2=ok
Exit code is 0 only if every leg passed. Common subsets:
# Just the Ubuntu legs (skip the Windows native build):
python test/compat/run_matrix.py --skip-windows
# A single Ubuntu version:
python test/compat/run_matrix.py --skip-windows --ubuntu 26.04
# Point at non-default saves / versions / scratch locations:
python test/compat/run_matrix.py \
--saves "D:/mc/saves" \
--versions "D:/mc/versions" \
--work "D:/tmp/ovmatrix"Renders and a machine-readable result.json for each leg land under
--work/out/<leg>/ (default --work is …/Temp/ov_compat_matrix). Open any
…/out/<leg>/<world>/index.html to eyeball a render.
- Docker running (Ubuntu legs). Base images
ubuntu:22.04/24.04/26.04are pulled on demand. - Minecraft client jars for each world's version under the versions dir, i.e.
versions/1.21.11/1.21.11.jar,versions/26.1/26.1.jar,versions/26.2/26.2.jar. These supply version-accurate textures (server jars contain no textures). - The three test worlds in the saves dir:
Derek-Single,Tester,GiveEr26_2. - A C compiler — gcc is installed inside the containers; the Windows leg needs the MSVC build tools already present on the host.
- Network access — each leg downloads the matching Pillow source distribution to get
Imaging.h(neither pip wheels nor apt ship Pillow's C headers).
| File | Role |
|---|---|
run_matrix.py |
Host orchestrator. Stages worlds, runs the Windows-native leg in a fresh venv and each Ubuntu leg in a container, collects result.json, prints the matrix. |
render_test.py |
The per-environment worker. Runs inside a leg: prints env + numpy/Pillow provenance, ensures Pillow headers, builds c_overviewer, renders each world, writes result.json. OS-agnostic (stdlib + project deps only). |
Dockerfile.ubuntu |
Parametrized image (--build-arg BASE=ubuntu:<ver>). Installs OS-provided deps via apt (python3-numpy python3-pil python3-networkx python3-requests, build tooling). |
entrypoint.sh |
Container entry: copies the read-only repo to a writable /work, then invokes render_test.py against the mounted worlds/versions/output. |
- Report the environment — OS, Python, and numpy/Pillow version and file path, so you can confirm which numpy/Pillow was used (apt vs pip, 1.x vs 2.x).
- Ensure Pillow C headers — read
PIL.__version__, download that exact Pillow sdist, extractsrc/libImaging/*.h, and expose them viaPIL_INCLUDE_DIR. - Build
c_overviewerwithsetup.py build_ext --inplaceagainst the leg's numpy. - Render each world to its own output dir with the matching client jar as
texturepath. - Judge — a world passes if Overviewer exits 0 and every requested dimension produced
> 0PNG tiles. The leg passes if all worlds pass.
| World | MC version | Dimensions rendered | Layout exercised |
|---|---|---|---|
Derek-Single |
1.21.11 | overworld | legacy (region/, DIM*) |
Tester |
26.1 | overworld, nether, end | new dimensions/minecraft/* |
GiveEr26_2 |
26.2 | overworld, nether, end | new layout + 26.2 texture relocations |
To add a world, extend the WORLDS dict in render_test.py (and have a matching
versions/<ver>/<ver>.jar and a copy of the world available).
The Ubuntu legs run in isolated containers that mount only the matching client jar. This is deliberate: on a developer machine with many Minecraft versions installed, Overviewer silently falls back to older jars for any texture missing from the target version's jar. That masks version-specific texture breakage (e.g. the Minecraft 26.2 bed/sign/pillar relocations) — a render can "pass" on the dev box yet fail for a real user who only has 26.2. The container is the honest test; always trust it over a local run.
- Ubuntu: use what the OS provides — numpy, Pillow, networkx, requests all come from
apt. Nothing runtime ispip-installed. (SETUPTOOLS_USE_DISTUTILS=localis set sosetup.pystill importsdistutilson Python ≥ 3.12, which removed it from stdlib.) - Windows: everything from
pipin a throwaway venv created by the orchestrator (relaxednumpy>=1.21,<3,pillow>=10,<13, plus networkx/requests — not the Windows-packaging extras).
result.json(per leg) contains the full env block and per-world tile counts — diff it across runs to see what changed.- A leg with
result == nullin the matrix means the container build/run itself failed (e.g. a compile error) — read that leg's stdout, not its (absent)result.json. - A world that builds but renders 0 tiles is almost always a missing/renamed texture
for that Minecraft version — run that one world with
--verboseagainst the matching jar to see the exactCould not find the textures …path.
In-place worker (uses the current interpreter's numpy/Pillow):
python test/compat/render_test.py \
--worlds "<staged worlds dir>" \
--versions "<versions dir>" \
--output "<output dir>"One Ubuntu image + container directly:
docker build --build-arg BASE=ubuntu:26.04 -t ov-compat-2604 -f test/compat/Dockerfile.ubuntu test/compat
docker run --rm \
-v "<repo>:/repo:ro" \
-v "<staged worlds>:/worlds:ro" \
-v "<versions>:/mc-versions:ro" \
-v "<output>:/output" \
ov-compat-2604Note: this harness is a developer/CI utility, kept separate from the unit test suite (
test/test_*.py). It shells out to Docker and a platform compiler and is not collected bypytest.