Is {chroot} being processed correctly during remot...
# general
b
Is {chroot} being processed correctly during remote execution? When I run
shell_commands
through remote execution, the tools can't be found. This is most likely due to how
PATH
is set. At time of remote execution
PATH
prints out as
{chroot}_binary_shims_*
. Is there a workaround to fill it in? I don't deny I could have other bugs causing it. I'm still exploring.
f
I do not believe that Pants replaces
{chroot}
in remote execution currently.
Pants cannot know the remote sandbox directory until it actually submits the execution request.
Pants would need to submit the request with a wrapper script to do the replacement.
Fortunately, Pants does use a wrapper script with remote execution when simulating append-only ("named") caches. That logic could be modified to also do the
{chroot}
replacement.
So some work needs to be done, but the logic to apply any sort of wrapper script in remote execution at least exists.
b
That's both good and bad. It seems like there's a path forward for supporting it if it's desired. But I was hoping it was just another easy option I was missing. I'm still way too new to pants to know its limits.
Thanks for your help and insight! I'm going to continue trying to work around it for bit longer.
I managed to hack around it. I just threw in a
PATH
update to each shell command to also look in
/usr/bin
. While it invalidates the tools argument, it's worth it for remote execution.
f
If it helps for caching, 2.23.x will have a new
path_env_modify
field on `shell_command`which can disable
PATH
modifications
(so no binary shims directory added to
PATH
if you don't want it. Thus Pants would use your PATH value as-is.)
b
Ooooo nice. I like that. I'll try it out. Thanks for the tip!
f
tangentially, there was already an open issue for
{chroot}
replacement in remote execution: https://github.com/pantsbuild/pants/issues/17519
b
Nice. I've given it a thumps up. I've done all I can for now to support that feature's development 🫡