Provide a fragment with paths to standard utilities like ln, grep, etc. #4681
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
team-Configurability
platforms, toolchains, cquery, select(), config transitions
type: feature request
Comments
aehlig
added
type: feature request
P1
mrkkrp
added a commit
to tweag/rules_haskell
that referenced
this issue
Mar 12, 2018
This generally kills hermeticity, so we must avoid using shell. The proposed approach with specifying locations of common utilities like ‘ln’ and ‘grep’ as argument to toolchain creating function should suffice until bazelbuild/bazel#4681 is implemented in Bazel itself. After that the ‘ln_location’ and ‘grep_location’ arguments may be removed.
mrkkrp
added a commit
to tweag/rules_haskell
that referenced
this issue
Mar 12, 2018
This generally kills hermeticity, so we must avoid using shell. The proposed approach with specifying locations of common utilities like ‘ln’ and ‘grep’ as argument to toolchain creating function should suffice until bazelbuild/bazel#4681 is implemented in Bazel itself. After that the ‘ln_location’ and ‘grep_location’ arguments may be removed.
jin
added
the
team-Configurability
|
@gregestren assigning this to configurability, please re-prioritize if it's not a P1. Thanks! |
|
@laszlocsomor - would #5265 cover this need? |
|
@gregestren -- Even though they are closely related, I don't think so. #5265 provides the foundation, this issue asks for the interface. |
|
My hope is that if binutils can be expressed as a toolchain, this request can be fulfilled by the toolchain API instead of a new |
gregestren
added
P3
|
Closing. We don't want to add to fragments, and a shell toolchain would solve the problems. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the feature request
If we had a fragment, e.g.
ctx.fragments.binutilsthat allowed us to get locations (full paths) to various utilities likelnandgrep, we could perform some actions (such as symlink creation) without resorting toctx.actions.run_shelloruse_default_shell_env = True(forctx.actions.run) and that in turn would allow for better hermeticity and control over build environment.What underlying problem are you trying to solve with this feature?
When we call e.g.
grep, some users report errors because although it is on theirPATH, it's not in standard location, and so we have to enableuse_default_shell_envfor ourrunactions or equivalently resort toctx.actions.run_shellwhich brings too much in scope and hurts hermeticity.Have you found anything relevant by searching the web?
No.
Any other information, logs, or outputs that you want to share?
No.
The text was updated successfully, but these errors were encountered: