Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

I just want it to work properly out of the box and not go reaching out to the internet for a bunch of stuff

<@U3M2APJQZ> Reasonable, but no one tackling. This is closest issue: <https://github.com/pantsbuild/pants/issues/4006>
You should come up with a concrete proposal and sketch it out in an issue / design doc to get the ball rolling

I don't think that particular issue will help with my use case (because at the point my distro package exists, user home directories with .cache might not yet)

but I'll think through how I'd like it to work and see if I can get some comments

<@U3DCNF8GN> I don't believe so - that would be welcome though

<@U04S45AHA> I think native engine is the odd one out in that bin folder, right? everything else is a runnable executable

(just spitballing here before putting up an official proposal) I'm thinking we could just have a "trust my $PATH and barf if executable isn't on it" mode

and then have a separate answer for native-engine that amounts to me just passing it in directly

The large orgs will not like trust my PATH, but as an option might be fine. I'm sure they'd rather have, trust a blob with this hash if you find it on my PATH.

well, I could also do a per-executable-type --get-protoc-here=/path/to/my/protoc and stuff that in my rc

$PATH just seemed more lightweight, but both work for me

then --get-native-engine-here=/path/to/my/native-engine

tbh even small orgs like ours don't want to trust user paths as our engineers delight in installing random gubbins on their laptops

yeah, I wasn't actually going to use user $PATHs

I think its fine to support PATH as an advanced option with caveats

I just have some pre-made wrapper machinery to set $PATH for binaries

although I'm leaning towards the per-tool --get-X-here= options

the url for binaries is global, but the suffix paths are per-binary