Is this problem insurmountable? It feels really w...
# development
w
Is this problem insurmountable? It feels really weird for me to be reaching for Docker or needing to install a standalone (but large) tool to my filesystem and then reference it by paths, when it could be downloaded and decompressed via Pants.
Specifically, I'm referring to ARM
gcc
stuff, but this will probably apply to the javascript backend with node and npm/npx as well. Is there any workaround where these tools still get placed in the Pants cached, and then the relative paths get sorted out from there - while not needing to expand these digests per call?
It's just one more friction point from adopting a tool in a project, where I have instructions other than:
Copy code
./pants --version
./pants fmt lint check ::
But instead pointing to a URL, downloading, installing, then setting URLs in the
pants.toml
b
Immutable inputs I think is what you're searching for?
w
Well, like, being able to use
ExternalTool
without any possible performance hit once downloaded and unzipped
Tools of potential ... vast.. sizes
b
Immutable inputs aren't part of the digest, but are linked into the sandbox
w
Okay, so outside of
DownloadedExternalTool
and that ilk
ImmutableInputs are a Rust feature?
rather, part of the Rust code?
e
Yes, but exposed as a Process field. You can request them. Just a sec ...
Then grep around to see uses of this.
w
yea, i mentioned in another #plugins thread recently: https://pantsbuild.slack.com/archives/C01CQHVDMMW/p1660580899022409?thread_ts=1660557566.904249&cid=C01CQHVDMMW … not using immutable inputs is slightly historical because it was 1) non-existent, and then 2) flaky for a while
👍 1
@fast-nail-55400 might have had a concrete issue in mind for that though
w
For tools that need a daemon or run other processes on the machine, I think those might have some weird behaviour - but for straight up code and binaries, I'll check out this immutable inputs business. Definitely feels like the correct approach
f
I just have not got around yet to having the Go backend use immutable inputs.
👍 1
(mostly since there is some some design work unrelated to immutable inputs. We probably should retain finding Go installed on the system; and there needs to be some design thought on how to configure downloads versus search local path.)
w
So, while I don't understand the nuances - I have to say that it's quite epic to be able to download and cache my ARM gcc toolchains, and have them run instantly in my Process with immutable_inputs
❤️ 1
Using this, I'm able to kibosh docker from my build pipeline, which is always a win