Fix PANTS_SHA install caching.

[jsirois]

Fixes #173

[jsirois]

I don't know of a good way to test this. Manually tested of course, but ensuring the result is cached requires poking at internals or turning off the network.

[kaos]

I don't know of a good way to test this.

In what context is the PANTS_VERSION_PROMPT_SALT available?

Two subsequent runs should have the same salt when this works, right?

[jsirois]

In what context is the PANTS_VERSION_PROMPT_SALT available?

Only when no Pants version is supplied (via pants.toml, PANTS_VERSION or PANTS_SHA)

Two subsequent runs should have the same salt when this works, right?

They should have no PANTS_VERSION_PROMPT_SALT env var set at all, that was the bug. That's a very direct test of internals that doesn't do much though. I'm hoping for an IT, something that actually tests a back slide robust to details.

[stuhood]

Thanks!

---

Re: testing: yea, had the same realization for #172. I'm not sure what to do about that... maybe a Pants plugin which reports some details of the invoke? But it would be a big abstraction leak for any of that information to actually be exposed to plugins, so...

[kaos]

In what context is the PANTS_VERSION_PROMPT_SALT available?

Only when no Pants version is supplied (via pants.toml, PANTS_VERSION or PANTS_SHA)

Two subsequent runs should have the same salt when this works, right?

They should have no PANTS_VERSION_PROMPT_SALT env var set at all, that was the bug. That's a very direct test of internals that doesn't do much though. I'm hoping for an IT, something that actually tests a back slide robust to details.

Oh right. Yea, in my mind it merely changed the value.

Guess an IT would have to capture network traffic or something like that maybe in order to detect the side-effect of using PANTS_SHA or not. Feels like a lot of work for a relatively small feature.