You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As found in #2657, the exec_interpreter attribute of the exec tools toolchain doesn't work with RBE.
What happens is the current_interpreter_executable() helper rule does declare_file(); symlink(), which puts the file at e.g. python/private/python3. Locally, this creates a symlink and when run, Python follows the symlink back to the actual location of the installed runtime ("python home"); this works. On RBE, however, it creates copy of the file. Python then can't find its way back to "python home" and fails to find e.g. shared libs, stdlib, etc.
The intent of the exec_interpreter field was to make it easy to run an interpreter in a build action by having it support DefaultInfo.files_to_run, which lets it be passed directly to ctx.actions.run(executable=...). Without a FilesToRun provider, the interpreter and its files have to be manually passed in. Additionally, because actions can't directly accept runfiles, it means the usual way to express the runfiles necessary for an executable (DefaultInfo.default_runfiles) can't be used.
While looking into solutions, a promising option looked something like:
Have py_runtime() return DefaultInfo with executable set.
In order to do this, re-declare the interpreter file as a file. This, apparently, works, even if it "clobbers" the original file. This is necessary because DefaultInfo.executable requires the file to be produced by the same rule.
In py_runtime_pair, have it put the DefaultInfo that py_runtime produced on the ToolchainInfo it returned
Alternative: create a new PyRuntimeInfo with a replaced interpreter field
Unfortunately, I didn't see a decent way to preserve the "exec_interpreter is a target that you can pass to ctx.actions.run" behavior. Maybe this would be possible if the underlying py_runtime target (which would have DefaultInfo.executable) could be more directly plumbed though. I'm not sure that's possible, though.
The text was updated successfully, but these errors were encountered:
As found in #2657, the
exec_interpreter
attribute of the exec tools toolchain doesn't work with RBE.What happens is the
current_interpreter_executable()
helper rule doesdeclare_file(); symlink()
, which puts the file at e.g.python/private/python3
. Locally, this creates a symlink and when run, Python follows the symlink back to the actual location of the installed runtime ("python home"); this works. On RBE, however, it creates copy of the file. Python then can't find its way back to "python home" and fails to find e.g. shared libs, stdlib, etc.The intent of the
exec_interpreter
field was to make it easy to run an interpreter in a build action by having it supportDefaultInfo.files_to_run
, which lets it be passed directly toctx.actions.run(executable=...)
. Without a FilesToRun provider, the interpreter and its files have to be manually passed in. Additionally, because actions can't directly accept runfiles, it means the usual way to express the runfiles necessary for an executable (DefaultInfo.default_runfiles) can't be used.While looking into solutions, a promising option looked something like:
Consumers are then able to do e.g.
Unfortunately, I didn't see a decent way to preserve the "exec_interpreter is a target that you can pass to ctx.actions.run" behavior. Maybe this would be possible if the underlying py_runtime target (which would have DefaultInfo.executable) could be more directly plumbed though. I'm not sure that's possible, though.
The text was updated successfully, but these errors were encountered: