`spin build`: detect if invoking Spin, and if so use current Spin binary
Although these are currently on the decrease with the new Python and JS SDKs, we have some cases in spin build where Spin invokes itself, specifically to run a plugin.
This is grand if Spin is on PATH, but is a problem if Spin is not on PATH, or the Spin on PATH is a different one from the one driving the build: this is biting the folks at Rancher Desktop (#2555).
We should consider detecting if Spin is invoking itself during build, and if so, to substitute in the path to the running Spin binary.
cc @jandubois
this is biting the folks at Rancher Desktop
I want to clarify that this is not a problem for Rancher Desktop; it is just something that I discovered while testing stuff (while working on bundling spin with Rancher Desktop).
I do think the current behaviour can be surprising, and ideally should be changed, but the change is not needed for Rancher Desktop itself. Only the issues listed in the "wish list" in #2555 would be helpful in future updates.
We should consider detecting if Spin is invoking itself during build, and if so, to substitute in the path to the running Spin binary.
I'm not a Rust developer, but it looks like the information is readily available via std::env::current_exe().
I don't know if you also have the situation where spin would invoke itself indirectly (spin invokes a plugin, and the plugin invokes spin again).
In that case it might be useful to extend the plugin "contract" to set an environment variable, e.g. SPIN_EXE to the current_exe() before invoking the plugin, so plugins can use that variable (if set) to call back into the same spin that has been invoking them.
But I kind of hope that this scenario does not even exist. 😄
We do currently set SPIN_BIN_PATH with std::env::current_exe for external commands. It might be nice to support something similar for spin build via shellexpand or envsubst, though perhaps we should go with something a little friendlier in that context: $SPIN?
Edit: It looks like spin build uses Exec::shell; that might inherently support shell substitution which would make shellexpand/envsubst redundant.