John Sirois

For that error, you're seeing the direct output of Pip. There is really nothing more Pex or Pants could do for that one, except, as you allude to, maybe blame...

Nope. If you read the issue I pointed to, even Pip folks aren't sure yet!

I have no say on this issue, I maintain Pex, not Pants. But, if I were you I'd at least push hard on Pants killing interpreter constraint OR support. It's...

I've been doing a general sweep over Pex issues over the last few months and found https://github.com/pex-tool/pex/issues/432 which would have Pex fail fast when Pants handed it something like `==3.11.*,==3.12.*`...

@logan-markewich for the OP interpreter constraint message you'll now see the following when Pants upgrades to Pex 2.20.1 (or you do): https://github.com/pex-tool/pex/pull/2542/files#diff-5d77c74e67c3b985b12a434cde0c358f59c3e381f4cb033e86e7a2046048c018R57-R80 ... assuming Pants shows warning stderr output from...

> this particular footgun needs to be tamed. In case it wasn't clear, I also initially thought this was a footgun; i.e.: I thought @logan-markewich mistakenly wrote down an IC...

I license my contributions to the `rust-lang/docker-rust` and `rust-lang/docker-rust-nightly` repositories under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

It's great you're being thorough here, but I think you could be even more thorough by just noting all PEX env vars not explicitly dealt with in the venv `__main__.py`...

@photoroman, you nailed it: > Perhaps the issue is related to the fact that ~/.cache/nce resides on a network drive (NFS4) in my setup? Exactly. The scie-pants locks will fail...

So @photoroman / @sureshjoshi this is a "known limitation" that there are no plans to "fix", at least in scie-jump since it would be a new feature to somehow support...