[Bug]: Graalpy fails embedding in windows 11 systems

Start by separating the three reported failures and reproducing mvn install -DskipTests -P graalpy on Windows. Inspect the graalpy-maven-plugin launcher/bootstrap classpath and Meson's mesonbuild/utils/vsenv.py, then compare the reported behavior with the linked upstream issues. Done means each confirmed failure has an isolated fix or an appropriate upstream report with a passing reproduction.

Describe the bug

GraalPy / graalpy-maven-plugin — Windows issues

Found while running mvn install -DskipTests -P graalpy (graalpy-maven-plugin, goal
process-graalpy-resources, packages comtypes, jsonpickle, numpy, <externalDirectory> pointing at a
project-local folder) on Windows 11.

Three separate, unrelated problems — recommend filing separately (likely against oracle/graalpython, based on
similar existing reports there and in oracle/graal).

Environment

• OS: Windows 11 Pro, build 10.0.26100.8875
• JDK running the plugin: GraalVM Community OpenJDK 25+37.1
• Maven: Apache Maven 3.9.14
• Visual Studio Build Tools 2022, 17.14.16 (MSVC 14.44.35207), "Desktop development with C++" workload

---

Issue 1 — graalpy-maven-plugin 25.3.4.1: launcher creation fails with FileNotFoundError for graalpy.exe on Windows

Symptom — process-graalpy-resources fails immediately, before any pip package installation:

[ERROR] Traceback (most recent call last):
[ERROR]   File "C:\Users\david\AppData\Local\Temp\create_launcher15929679633436647223.py", line 6, in <module>
[ERROR]     shutil.copy(vl, tl)
[ERROR] FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\david\\AppData\\Local\\org.graalvm.polyglot\\python\\python-home\\a2140a92df5a4bff360431b210f2dfe16199e2daeae7c603\\Lib\\venv\\scripts\\nt\\graalpy.exe'

Root cause — the plugin's launcher-creation script tries to shutil.copy a file named graalpy.exe out of
the extracted GraalPy distribution's Lib\venv\scripts\nt\. That file does not exist in the 25.3.4.1 Windows
embeddable distribution — the directory only ships activate.bat, deactivate.bat, venvlauncher.exe,
venvwlauncher.exe. Confirmed by inspecting the full extracted python-home tree: no file named graalpy.exe
exists anywhere in it. This lines up with the CPython 3.13 venv change that replaced copying an
interpreter-named python.exe/pythonw.exe into venv\Scripts with the generic venvlauncher.exe/
venvwlauncher.exe redirectors — the 25.3.x distribution follows that newer layout, but the plugin's Windows
launcher step still assumes an interpreter-named exe exists to copy.

Fix — pin graalvm.version to 25.0.2 or 25.2.4. Both produce a working graalpy.exe at
<externalDirectory>/venv/Scripts/graalpy.exe. (25.2.4 doesn't show up in Maven Central's solrsearch index,
which reports 24.2.1 as latest, but it resolves fine from a standard Nexus/Central proxy — index staleness,
not a nonexistent version.)

Possibly related upstream reports: oracle/graal#12059, oracle/graalpython#434.

---

Issue 2 — Meson (vendored in numpy's sdist) can't detect cl.exe when the newest installed VS instance is "Visual Studio 18" (2026)

Symptom — with the plugin pinned to a working version, pip install numpy builds numpy from source via its
vendored Meson (1.5.2), which fails even though a VS 2026 Build Tools instance (18.9.2) is installed
alongside VS 2022:

Activating VS 18.9.2
..\meson.build:1:0: ERROR: Unknown compiler(s): [['icl'], ['cl'], ['cc'], ['gcc'], ['clang'], ['clang-cl'], ['pgcc']]
Running `cl /?` gave "[Errno 2] No such file or directory: 'cl'"

Root cause — Meson's mesonbuild/utils/vsenv.py (1.5.2) locates a VS instance via vswhere.exe -latest -prerelease -requiresAny -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -requires Microsoft.VisualStudio.Workload.WDExpress -products * -utf8 -format json — no version filter, so it always
picks the newest qualifying instance (VS 2026 here). cl.exe genuinely exists and runs fine directly at
...\Microsoft Visual Studio\18\BuildTools\VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64\cl.exe, so the VS install
itself is not broken. Meson's post-vswhere activation (running vcvarsall.bat via a generated temp .bat,
capturing the environment, reapplying it to its own process) fails to produce a PATH that makes cl.exe
resolvable for this VS major version/instance layout, despite reporting Activating VS 18.9.2 with no error.

Confirmed by reusing an already-created venv's graalpy.exe and running graalpy.exe -m pip wheel numpy --no-deps directly from inside an officially-opened "x64 Native Tools Command Prompt for VS 2022" (bypassing
the plugin's own launcher-creation step): Meson correctly detected cl.exe from the VS 2022 instance and ninja
began real compilation. So VS 2022 works correctly once it's the active toolchain; the defect is in how Meson
selects/activates whichever instance vswhere -latest returns when that's a VS 18 (2026) instance.

Fix — uninstall/avoid having a VS 2026 instance registered alongside older ones, so vswhere -latest
resolves to a VS version Meson 1.5.2 supports (e.g. VS 2022).

---

Issue 3 — graalpy-maven-plugin's own bootstrap classpath omits the Truffle NFI language, so anything needing _ctypes fails

Symptom:

[INFO] Running GraalPy: ... com.oracle.graal.python.shell.GraalPythonMain C:\Users\david\AppData\Local\Temp\create_launcher....py
[ERROR] ERROR: ModuleNotFoundError: No module named '_ctypes'

Root cause — reproduced directly by invoking GraalPythonMain with the exact classpath the plugin itself
logs for its internal bootstrap:

$ java ... -classpath <plugin's own logged classpath> com.oracle.graal.python.shell.GraalPythonMain -c "import _ctypes"

java.lang.IllegalStateException: No language for id nfi found. Supported languages are: [python, regex]
	at com.oracle.truffle.polyglot.PolyglotEngineImpl.findLanguage(PolyglotEngineImpl.java:952)
	at com.oracle.graal.python.builtins.modules.ctypes.CtypesModuleBuiltins$DlOpenNode.load(CtypesModuleBuiltins.java:673)
	at com.oracle.graal.python.builtins.modules.ctypes.CtypesModuleBuiltins.postInitialize(CtypesModuleBuiltins.java:270)
	...

GraalPy's _ctypes module is implemented on top of Truffle's NFI (Native Function Interface) language. The
classpath graalpy-maven-plugin constructs for its own internal GraalPythonMain invocations only registers
the python and regex Truffle languages — nfi is never on it. Any code path needing _ctypes (explicit
import ctypes/_ctypes, comtypes, and apparently some GraalPy versions' own site initialization) fails
with this IllegalStateException, which GraalPythonMain surfaces to the user as the more confusing
ModuleNotFoundError: No module named '_ctypes'.

Fix, confirming the diagnosis — adding both missing artifacts to the classpath resolves it:

$ java ... -classpath <same classpath>;truffle-nfi-25.0.2.jar com.oracle.graal.python.shell.GraalPythonMain -c "import _ctypes"
polyglot.ForeignException: Unknown NFI backend 'native'.

$ java ... -classpath <same classpath>;truffle-nfi-25.0.2.jar;truffle-nfi-libffi-25.0.2.jar com.oracle.graal.python.shell.GraalPythonMain -c "import _ctypes; print('ctypes ok')"
ctypes ok

Both org.graalvm.truffle:truffle-nfi (the NFI language) and org.graalvm.truffle:truffle-nfi-libffi (the
native NFI backend implementation) are required — truffle-nfi alone finds the language but has no backend
for it. Both artifacts are published and versioned in lock-step with everything else on that classpath
(org.graalvm.truffle:truffle-nfi-libffi:<graalvm.version>), so this looks like a straightforward missing
dependency in graalpy-maven-plugin's own POM/classpath construction for its bootstrap invocations. It is not
fixable from a consuming project's pom.xml: the plugin forks a separate java process with a classpath it
resolves internally (via its own bundled dependency downloader), not the Mojo's own plugin-dependency
classpath.

---

Note on build resource usage (not a bug, but worth flagging for anyone reproducing)

Once Issues #1 and #2 are worked around, building numpy from source via GraalPy on Windows hits a further,
unrelated resource wall: Meson/ninja parallelizes numpy's ~526 build steps, several of which invoke
graalpy.exe as a subprocess (e.g. _build_utils/process_src_template.py, generate_umath.py) — each such
invocation is a full JVM/GraalVM engine start. Running enough of these concurrently exhausted the Windows page
file:

OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(...) failed;
  error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
There is insufficient memory for the Java Runtime Environment to continue.

Building native extensions for GraalPy on Windows via ninja's default parallelism is memory-hungry (many
concurrent JVMs); a larger page file or constrained parallelism (e.g. -j1) may be needed.

Operating system

Linux

CPU architecture

x86_64

GraalPy version

25.3.4.1

JDK version

25

Context configuration

No response

Steps to reproduce

See the description of the issues above

Expected behavior

That is should be possible to embed graalpy via maven plugin with common dependencies and get a simply running test with those imports.

Stack trace

Additional context

No response