cue
cue copied to clipboard
Expose the GOARCH runtime constant to CLI users
Is your feature request related to a problem? Please describe.
I'd like to access information about the runtime that's executing the cue
CLI, so I can fetch appropriate binaries for an outside-of-CUE-land purpose. I can already access the OS information via the os
system tag, and it seems like a bit of an arbitrary choice not to be able to do the same for the only other similarly-situated runtime variable that Go makes available: runtime.GOARCH
.
Describe the solution you'd like
I'd like arch
to be available as a system tag, when the --inject-vars
flag is used.
I have implemented this as PR #1689.
Describe alternatives you've considered
I currently hackily script around the cue
invocation and interrogate various uname
outputs. I have an incomplete map of uname -m
to possible GOARCH variants that I populate manually, and feed into the cue
invocation as tags. The CLI runtime has this information available at its fingertips, and it doesn't seem like a stretch to ask it to expose the info.
Additional context
Go's runtime
package makes 3 top-level constants available: the name of the tool that built the running binary, the OS, and the architecture. Of those, only the last 2 are relevant to the in-CUE consumer, and it seems arbitrary to make only 1 of them available as a system variable.
I don't believe there's a slippery-slope argument to counter, here. The associated PR (#1689) isn't serving as precedent to open the flood gates to a wider set of variables: it's just going some small way to realign the capabilities of cue
CLI users with folks who are consuming CUE in Go.
I vaguely remember this coming up at the time we introduced tag vars. Sounds good to me. But I defer to @mpvl for a final decision.
Yes, adding the arch is in line with the other supported values.