<@U01PZK60W2F> I'm looking at <https://github.com/...
# development
e
@curved-television-6568 I'm looking at https://github.com/pantsbuild/setup/pull/123 and am wondering how this is used in practice.
Currently it can do anything bash can do, but do you actually only use it like an
.env
file to source env vars?
I'm hoping the latter, but it also seems like the can of worms may be already open.
c
Only env vars. Using bashisms to optionally set them only.
e
Ok. That's good to know. I'll have to contemplate the unknown uses that may have sprouted and what to do about them.
c
Hmm.. at svs I’ll have to reach out to see if there were some cmd involved in order to produce some of the values.. like running git to get a rev or so
You want to lock this down more..?
e
The driver is not that, its starting to think about a native launcher (Rust). That can certainly parse .env and set env, but arbitrary bash is another thing.
👍 1
I'm thinking of transition smoothness mainly. I'd like this to be seamless.
Native launcher aside, if there still is a pants script - which there will need to be probably for the transition, there will also be a side-by-side pants.ps1 and then you're stuck too, but at least that's a totally new use case and so can define new rules with 0 transition.
c
ah, ok, I see. that makes sense yea.
I guess there are other tools one may employ to get the same effect, like direnv or something along those lines
e
Yeah. The loose idea is to use the rust-dotenv crate to try to parse .env and maybe the .pants.bootstrap, but the latter will definitely fail if there is anything bashy above and beyond; so I wanted to check the intent at least. Thanks, this is good background to think further with.
h
How much have we publicized PANTS_BOOTSTRAP? Do we expect it to be used in the wild?
e
I mean, once its public you have to assume you break someone.
Until I cry uncle, I'll assume that anyway.
c
I’ve prescribed that solution at least two or three times, a couple of them just the other week or so.. even wrote https://github.com/pantsbuild/pants/discussions/17633 😛
👍 1
e
Circling back, supporting
.pants.bootstrap
and that use case was easy enough. As long as the only meaningful side effects of that file are setting env vars, that's covered.
~100us startup overhead does go to 2ms though for a
.pants.bootstrap
with just
: ${GIT_COMMIT:=$(git rev-parse HEAD)}
c
I’ll take that hit 😉 as long as it’s opt-in (read it as 2ms in case the file exists not otherwise, right?)
e
Correct.
👍 1
c
I guess most of those 2ms is the
git
command…
e
1ms for bash 1ms for git
c
gotcha