Borrow npx along with node, since the recipe needs both
The container-userland recipe put a node on the path and said to run the
command with that node found first, which is not enough. npx is not part of
node but a script beside it, so a machine whose node is too old to parse the
bundle has an equally old npx, and a path carrying only the borrowed node
still finds the old one: on a Rocky 8 workstation `npx` remained
/usr/bin/npx, npm 6.14.11 belonging to the system's node 10, running under a
borrowed node 22. The recipe now writes a second wrapper for it, and says why
it is needed, in the page and in the README both.
Verified on the same Rocky 8.10 workstation the recipe was written on (glibc
2.28, RTX 6000 Ada, driver 580.159.04): with both wrappers on the path the
command the page hands out runs verbatim, reports build e53205f, and Dawn
brings up the adapter as NVIDIA 580.159.04 on the host.
2 changed files+17−2
README.mdmodified+4−1View file
@@ -195,7 +195,10 @@ What does work is to borrow only the userland from a container image and run
195195 node through its loader, on the host, leaving the GPU, `/dev` and `/proc`
196196 exactly as they were; the host's own `/usr/lib64` stays last on the library
197197 path, since the NVIDIA libraries and the Vulkan loader have to match the
198-running kernel module. The page carries that recipe, folded away beside the
198+running kernel module. Note that `npx` must be borrowed along with `node`,
199+being a script beside node rather than a part of it: a machine whose node is
200+too old has an equally old npx, and a path carrying only the borrowed node
201+still finds that one. The page carries that recipe, folded away beside the
199202 command it belongs to, along with what the other common failures mean —
200203 they are worth writing down where someone will meet them, since none of them
201204 is guessable from the error alone.
index.htmlmodified+13−1View file
@@ -108,7 +108,12 @@ printf '#!/bin/sh\nexec %s --library-path %s %s "$@"\n' \
108108 $U/usr/local/bin/node > ~/turing-bin/node
109109 chmod +x ~/turing-bin/node
110110
111-# 3. run the command above, with that node found first
111+# 3. and the borrowed npx, which is a script rather than part of node
112+printf '#!/bin/sh\nexec ~/turing-bin/node %s "$@"\n' \
113+ $U/usr/local/lib/node_modules/npm/bin/npx-cli.js > ~/turing-bin/npx
114+chmod +x ~/turing-bin/npx
115+
116+# 4. run the command above, with those found first
112117 export PATH=~/turing-bin:$PATH</pre>
113118 <p>The host's own <code>/usr/lib64</code> stays last on that library
114119 path, and is where the NVIDIA libraries and the Vulkan loader come
@@ -117,6 +122,13 @@ export PATH=~/turing-bin:$PATH</pre>
117122 unpack the image, which
118123 <code>--root /tmp/$USER/store --runroot /tmp/$USER/run</code> on each
119124 podman command works around.</p>
125+ <p>Note that <code>npx</code> has to be borrowed as well as
126+ <code>node</code>. It is not part of node but a script beside it,
127+ so a machine whose own node is too old has an <code>npx</code> too
128+ old to go with it, and putting only a node on the path leaves that
129+ old one to be found. Its symptoms are its own rather than the
130+ version error above, since it is a different program from the npx
131+ of any current node.</p>
120132 <p><code>WebGPU is not available</code>, or no adapter at all, means
121133 there is no GPU to reach: Dawn goes through Vulkan on Linux and Metal
122134 on macOS, so a machine without a GPU, or with one whose driver is not