#17781 Allow associating system tools (not managed by pants) with files/targets, for less repetition in `experimental_shell_command(tools=)` and friends Issue created by huonw Is your feature request related to a problem? Please describe. In #17716 (comment), we notice that the new

experimental_run_in_sandbox

and

experimental_shell_command

requires specifying the system tools required for running a command. This seems slightly wrong: the system tools are (generally) an implementation detail of the file/package/... itself, rather than of the context that runs it. If a single file is run by multiple targets, currently every one of those targets needs to specify

tools

, e.g.:

# example.sh
mkdir $1
touch $1/bar
mv $1/bar $1/baz

# BUILD
shell_sources(name="example")

experimental_run_in_sandbox(name="one", runnable="./example.sh", argv=["dir1"], tools=["mkdir", "touch", "mv"])
experimental_run_in_sandbox(name="two", runnable="./example.sh", argv=["dir2"], tools=["mkdir", "touch", "mv"])

Describe the solution you'd like Maybe the system tool dependencies could be modelled as 'normal' dependencies, e.g.:

# BUILD
shell_sources(
  name="example",
  dependencies=["system_tools#mkdir", "system_tools#touch", "system_tools#mv"]
)

# these sandboxes will automatically add the appropriate tools to PATH
experimental_run_in_sandbox(name="one", runnable="./example.sh", argv=["dir1"])
experimental_run_in_sandbox(name="two", runnable="./example.sh", argv=["dir2"])

where

system_tools#

is hypothetical syntax for magic system tool targets. It could also be

dependencies=[system_tool("mkdir"), system_tool("touch"), ...]

and/or

dependencies=[system_tools("mkdir", "touch", ...)]

, although those could be implemented as a macro around some base 'fully explicit' syntax too. Describe alternatives you've considered Other options might be: 1. explicit targets for system tools (e.g.

system_tool(name="mkdir", tool="mkdir")

, maybe a generator like

system_tools(tools=["mkdir", "touch", ...)

too) which can then be depended on like normal:

//:mkdir

or whatever 2. a slight generalisation of something like #17277, e.g.

external_tool(name="mkdir", source=system_source(executable="mkdir"))

(can be wrapped up into a macro/generator too), or some way to phrase it with the

file

version referenced at the end. 3. an new option like

system_tools

to all targets, that represents a separate stream of dependencies. NB. for codegen like

experimental_shell_command

, this presumably would require splitting into

execution_system_tools

and

output_system_tools

(along the lines of the

dependencies

split in #17743), and hence this seems poor. Additional context N/A pantsbuild/pants