[PR #10] [CLOSED] Find Blender 5.x installs, whose folder is versioned #55

New issue

Closed

opened 2026-10-15 20:53:03 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 20:53:03 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/rehan-remade/universal-modder/pull/10
Author: @musicforgirls
Created: 10/2/2026
Status: ❌ Closed

Base: main ← Head: fix/blender-5x-versioned-install-path

📝 Commits (1)

89b38f0 Find Blender 5.x installs, whose folder is versioned

📊 Changes

2 files changed (+63 additions, -3 deletions)

View changed files

📝 tests/test_um.py (+48 -2)
📝 um/render3d.py (+15 -1)

📄 Description

Problem

um render3d could not find Blender 5.x on Windows.

blender_bin() hardcoded a single install path:

r"C:\Program Files\Blender Foundation\Blender\blender.exe"

Blender 5.x installs to a versioned folder instead:

C:\Program Files\Blender Foundation\Blender 5.2\blender.exe

So the fallback missed, blender was usually not on PATH, and the command died with Blender not found: install it... for anyone on Blender 5.x. The workaround is to export BLENDER=/path/to/blender yourself, but the error message never mentions that Blender moved.

Fix

Glob Blender*/blender.exe under Blender Foundation and pick the highest version numerically:

winroot = Path(os.environ.get("ProgramFiles", r"C:\Program Files")) / "Blender Foundation"
cands = ["/Applications/Blender.app/Contents/MacOS/Blender"]
cands += sorted((str(p) for p in winroot.glob("Blender*/blender.exe")),
                key=_blender_sort_key, reverse=True)

Two details worth calling out:

Numeric, not lexical. _blender_sort_key exists so Blender 10.0 correctly beats Blender 9.0. A plain string sort would get that wrong.
ProgramFiles is read from the environment instead of hardcoding C:\Program Files, so a non-default install location also works. This also makes the function testable on any platform.

The BLENDER env var and PATH still take priority, and the macOS .app path is unchanged, so this is purely additive.

Second fix, included because it blocked verification

tests/test_um.py shelled out to which at import time:

@pytest.mark.skipif(subprocess.run(["which", "ffmpeg"], capture_output=True).returncode, ...)

which does not exist on Windows, so this raised FileNotFoundError during collection and the entire test module failed to collect. That meant zero tests in the file could run on Windows, not just the ffmpeg-dependent one. Replaced with shutil.which("ffmpeg") is None, which is both portable and cheaper (no subprocess per run).

I fixed this in the same PR because I could not otherwise verify the Blender fix above. Happy to split it into its own commit if you prefer.

Testing

New tests in tests/test_um.py cover the BLENDER env var winning, discovery of a versioned Blender 5.2 folder, newest-version-wins (including the 10.0 vs 9.0 case), and the not-found path.

Check	This branch	Clean `15d6f9d`
`uv run --with pytest pytest -q tests`	23 passed, 3 failed	19 passed, same 3 failed
`um publish check .`	PASS, 234 files, 0 warnings	—

I confirmed the 3 remaining failures are pre-existing by running the suite in a throwaway worktree at 15d6f9d. They are unrelated to this change (test_publish_check, test_repo_knowledge_is_valid, test_kb_new_check_search).

Note on CI

um kb check --index currently fails on main because knowledge/INDEX.md is out of date (run um kb index). CI runs that check on every PR, so this one will go red for a reason that has nothing to do with it. I deliberately left it alone rather than mixing an index regeneration into a bugfix, but a maintainer will need to run um kb index separately.

Verified against Blender 5.2.2 LTS on Windows 11, found at the versioned path with no BLENDER variable set.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/rehan-remade/universal-modder/pull/10 **Author:** [@musicforgirls](https://github.com/musicforgirls) **Created:** 10/2/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/blender-5x-versioned-install-path` --- ### 📝 Commits (1) - [`89b38f0`](https://github.com/rehan-remade/universal-modder/commit/89b38f000cd5eb280750d2fff9ef46c508d17dc8) Find Blender 5.x installs, whose folder is versioned ### 📊 Changes **2 files changed** (+63 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `tests/test_um.py` (+48 -2) 📝 `um/render3d.py` (+15 -1) </details> ### 📄 Description ## Problem `um render3d` could not find Blender 5.x on Windows. `blender_bin()` hardcoded a single install path: ```python r"C:\Program Files\Blender Foundation\Blender\blender.exe" ``` Blender 5.x installs to a **versioned** folder instead: ``` C:\Program Files\Blender Foundation\Blender 5.2\blender.exe ``` So the fallback missed, `blender` was usually not on `PATH`, and the command died with `Blender not found: install it...` for anyone on Blender 5.x. The workaround is to export `BLENDER=/path/to/blender` yourself, but the error message never mentions that Blender moved. ## Fix Glob `Blender*/blender.exe` under `Blender Foundation` and pick the **highest version numerically**: ```python winroot = Path(os.environ.get("ProgramFiles", r"C:\Program Files")) / "Blender Foundation" cands = ["/Applications/Blender.app/Contents/MacOS/Blender"] cands += sorted((str(p) for p in winroot.glob("Blender*/blender.exe")), key=_blender_sort_key, reverse=True) ``` Two details worth calling out: - **Numeric, not lexical.** `_blender_sort_key` exists so `Blender 10.0` correctly beats `Blender 9.0`. A plain string sort would get that wrong. - **`ProgramFiles` is read from the environment** instead of hardcoding `C:\Program Files`, so a non-default install location also works. This also makes the function testable on any platform. The `BLENDER` env var and `PATH` still take priority, and the macOS `.app` path is unchanged, so this is purely additive. ## Second fix, included because it blocked verification `tests/test_um.py` shelled out to `which` at **import** time: ```python @pytest.mark.skipif(subprocess.run(["which", "ffmpeg"], capture_output=True).returncode, ...) ``` `which` does not exist on Windows, so this raised `FileNotFoundError` during **collection** and the entire test module failed to collect. That meant *zero* tests in the file could run on Windows, not just the ffmpeg-dependent one. Replaced with `shutil.which("ffmpeg") is None`, which is both portable and cheaper (no subprocess per run). I fixed this in the same PR because I could not otherwise verify the Blender fix above. Happy to split it into its own commit if you prefer. ## Testing New tests in `tests/test_um.py` cover the `BLENDER` env var winning, discovery of a versioned `Blender 5.2` folder, newest-version-wins (including the `10.0` vs `9.0` case), and the not-found path. | Check | This branch | Clean `15d6f9d` | |---|---|---| | `uv run --with pytest pytest -q tests` | 23 passed, 3 failed | 19 passed, **same 3 failed** | | `um publish check .` | PASS, 234 files, 0 warnings | — | I confirmed the 3 remaining failures are pre-existing by running the suite in a throwaway worktree at `15d6f9d`. They are unrelated to this change (`test_publish_check`, `test_repo_knowledge_is_valid`, `test_kb_new_check_search`). ## Note on CI `um kb check --index` currently **fails on `main`** because `knowledge/INDEX.md` is out of date (`run um kb index`). CI runs that check on every PR, so this one will go red for a reason that has nothing to do with it. I deliberately left it alone rather than mixing an index regeneration into a bugfix, but a maintainer will need to run `um kb index` separately. Verified against Blender 5.2.2 LTS on Windows 11, found at the versioned path with no `BLENDER` variable set. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 20:53:03 +00:00