The wheel installs flatc through setup.py's get_executable_name(), so on
Windows the file is executorch/data/bin/flatc.exe. _get_flatc_path() asked
for "flatc", is_file() was False, and the lookup fell through to the bare
name on PATH. That only resolves when the environment's Scripts directory is
on PATH, where the flatc console-script shim lives. Without it, anything that
serializes through flatc, such as to_executorch() after XnnpackPartitioner,
raised FileNotFoundError: [WinError 2].
Use the suffixed name on win32 and add a test for both platform spellings.
This PR was authored with AI assistance (Claude Code); I reviewed every changed line and take responsibility for it.
Summary
Fixes #23989
On Windows the wheel packages flatc through
setup.py'sget_executable_name(), so the binary isexecutorch/data/bin/flatc.exe._get_flatc_path()inexir/_serialize/_flatbuffer.pyaskedexecutorch.data.binforflatc,is_file()wasFalse, and the lookup fell back to a bareflatconPATH. That resolves only when the environment'sScriptsdirectory is onPATH(pip puts theflatcconsole-script shim there). Called by the interpreter's full path,to_executorch()afterXnnpackPartitionerraisedFileNotFoundError: [WinError 2].The change asks for
flatc.exeonwin32and leaves the other platforms and the first candidate (flatbuffers-flatc, used by the Buck/PAR build) as they were. This completes #19899, which added theexecutorch.data.bincandidate with the Linux/macOS spelling only.All eight modules that run flatc import the same helpers from this file, so no other call site needs a change; the audit is in #23989.
Test plan
Added
TestGetFlatcPathtoexir/_serialize/test/test_flatbuffer.py. It fakes anexecutorch.data.bindirectory containing only the wheel's filename and checks that_get_flatc_path()returns that file:flatc.exewithsys.platformset towin32,flatcforlinuxanddarwin. It patches the module's cache globals so it does not depend on test order.Both run on the Windows job (
pytest-windows.inilistsexir/_serialize/testandbackends/xnnpack/test/serialization).Measured on Windows 11 x64, Python 3.12.10, a fresh venv with the PyPI
executorch==1.5.1win_amd64 wheel andtorch==2.14.0+cpu,FLATC_EXECUTABLEunset, no flatc onPATH, interpreter called by full path. I did not build the wheel from source: for "after" I replacedexir/_serialize/_flatbuffer.pyinside that install with the file from this branch. The_get_flatc_path()block in the 1.5.1 wheel is identical tomain, so the "before" is the same code.The failing set after the change is a strict subset of the set before it: the two that went green are the new test and
test_serialize_xnnpack_binary, and nothing new fails. The 4 that remain (test_named_data_storex2,test_programx1,test_ptnx1, the last with several failing subtests) fail identically with and without this change. The first three are assertions about named-data alignment and segment handling whose fixes (#23517, #23340) landed onmainafter v1.5.1, so I believe they aremain's tests running against the older 1.5.1 wheel code; I did not run them against a build frommain, and I did not trace thetest_ptnone.Not covered: I could not run the new test on Linux or macOS (only its
linux/darwincases withsys.platformpatched on Windows), and nothing was run under Buck.ufmt2.8.0 /usort1.0.8 /black24.4.2 andflake86.1.0 at the versions inrequirements-lintrunner.txtare clean on both files; I did not run the fulllintrunner(nomypy/pyre).cc @nil-is-all