Excited to announce my latest invention! The

external_tool

target! https://github.com/pantsbuild/pants/pull/17277 If a picture is worth 1000 words, an example has to be worth something:

external_tool(
    name="gh",
    source=http_source(
        url="<https://github.com/cli/cli/releases/download/v2.18.0/gh_2.18.0_linux_amd64.tar.gz>",
        sha256="6b091b0b21ee8b0ec257920968905dc065505f5718e5a7de1e9d287320869ef8",
        len=9230158
    ),
    exe="gh_2.18.0_linux_amd64/bin/gh"
)

$ ./pants run //:gh -- --version
gh version 2.18.0 (2022-10-18)
<https://github.com/cli/cli/releases/tag/v2.18.0>

Now you can declare tools in that Pants will take care of downloading and sandboxing, and share those with your org. Or run them as part of other scripts. Have fun 😈

your example makes me “get the picture”, so that ought to be worth a 1000 words too, right? 😛

Interesting! So a good way to pin a version of a tool across a repo. Which really matters for, e.g., terraform, and other tools that generated versioned state

And to write scripts that down require prior work (download)

Neat! Let's do a tweet of this when the feature lands.

will definitely need the cross-platform consideration i think… that’s a lightly tricky situation, because BUILD file evaluation will always occur on the local platform, but if the

http_source

is going to be consumed in a target marked to run in a different

environment

, then it should use that platform. so whatever syntax triggers cross platform needs to actually defer execution until codegen in order to get the “right” platform.

I think we all agree on that, just that the syntax for declaring all the urls/shas/lens is up for grabs

Any thoughts on security implications of this? You can already do a lot with python anyway, but I'm curious if any recommendations would flow out of this beyond the usual things like only pull from trusted sources.

I think same as usual. Don't download and run what you don't trust. At least with the hashing, supply chain attacks are mitigated