<@U02KAN6061E> <https://pantsbuild.slack.com/archi...
# development
a
@bitter-ability-32190 https://pantsbuild.slack.com/archives/C046T6T9U/p1680111884221879?thread_ts=1680080947.835679&amp;cid=C046T6T9U
runnable_dependencies
as implemented over in
adhoc_process_support
resolves the envvars needed to run a target; so the infrastructure for embedding a JVM is there in
runnable_dependencies
. Getting
runnable_dependencies
into more places would solve Tal’s problem
There’s a good argument in favour of working to implement scoped dependencies a bit more widely, since there’s clearly value in having more things be able to pull in runnable dependencies
b
Can you point me to where in the docs/code that's the case?
I don't think today any code going into
pytest_runner
for instance expects env vars coming from the transitive targets
a
Right,
runnable_dependencies
only works in
adhoc_tool
and
shell_command
b
So the point stands. When considering how a particular Target should arrive in a sandbox should include not only diogests, but env vars
a
Right, I’m saying that is implemented for
adhoc_tool
already: https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/adhoc/adhoc_tool.py#L137-L167 It’s just that only
runnable_dependencies
has the support for resolving those envvars
but as a result of that,
runnable_dependencies
is not transitively resolved
b
oh interesting
There's certainly some shifting of paradigms going on I haven't paid attention to
a
this is why that field lives an
experimental
package
It’s extremely necessary to run node.js runnables (e.g.
yarn
is implemented as a script with a
#!/usr/bin/env node
)