https://pantsbuild.org/ logo
Join Slack
Powered by
Why are `tools` part of `shell_command` instead of...
# general
h
Why are 
tools
part of 
shell_command
instead of 
shell_source
? It seems like if I have a common 
helper.sh
file that I 
source
into others, I'd have to repeat the 
tools
that 
helper.sh
needs every time I write a new 
shell_command
. Anything I'm missing here?
f
It is a use case that likely was not identified before. And you have noticed it is an issue and are now raising it. Maybe 
tools
should be added 
shell_source
(and remain on 
shell_command
)? Then the tools used for an invocation would be the merging of the 
tools
on the 
shell_command
plus all of the tools set on any 
tools
field on the 
shell_source
fields involved.
👍 1
b
There’s a few issues touching on this: • https://github.com/pantsbuild/pants/issues/17781 • https://github.com/pantsbuild/pants/issues/18320 Not that helpful though! There’s been no progress towards them for a while
👀 1
To alleviate severe repetition in cases you describe, a variable or macro with the relevant tools could be used
f
To alleviate severe repetition in cases you describe, a variable or macro with the relevant tools could be used
That might work for setting 
tools
on 
shell_command
targets but it seems to me that it would still require that the 
shell_command
target have knowledge of what tools are used by any 
shell_source
dependencies. I submit it would be better to allow encoding that 
tools
knowledge at the location it is used, that is the 
shell_source
target.
(and then still use macros or 
__defauts__
to set 
tools
as needed)
b
Yeah, that’s just a short term workaround until a real solution (like the issue I filed) exists, eg instead of writing it out N times, have a 
tools = […]
variable to pass to each of the N `shell_command`s that use a particular 
shell_source
. Sorry for the confusion
f
No confusion at all! I believe both solutions should be implemented.
Using a macro or the 
__defaults__
mechanism allows reducing the boilerplate of defining it on the 
shell_source
. Having the ability to define it on a 
shell_source
means it is defined for the shell file which needs the tool. Thus, readers of the code will understand why it is there. Whereas, if it was defined on the 
shell_command
, readers of that target would need to understand what 
tools
were used by the transitive set of dependencies which could be confusing to them.
3 Views
Open in Slack
PreviousNext
Powered by