John Sirois

Both backtraces you provide include /home/johan which implies Linux (WSL) from your initial report. Your initial report also says this happens on MacOS. Is the MacOS backtrace ~exactly the same?

Ok, thanks for checking into that. I run on Linux myself, but Arch. Do you happen to have the docker container FROM that the MacOS user uses? Alternatively, do you...

Alright - thank you. That gave me enough to repro. I'm drilling in presently and will probably file a bug over in Pex and link that back here.

Well, pex==2.1.100 works. I can flip and back and forth from 2.1.99 to 2.1.100 and repro failure on 2.1.99 and succeed on 2.1.100. There is no seemingly related fix in...

Ok, I can make 2.1.99 pass by eliminating both `--target-system` flags, which does put this back in the wheel-house of the 2.1.100 fix, but I still can't grok how yet.

Except! My machine has cargo / rust and the docker image does not. The case that brought 2.1.100 to my attention involved an sdist that built (or failed to build)...

Ok, yeah, `pywinpty` again here due to the top level `jupyterlab==4.0.0a26` requirement -> `jupyter-server=1.16.0` -> `pywinpty; os_name == \"nt\"`. On the docker image `pywinpty` fails to build: ``` root@33d849f56faf:/# pex.venv/bin/pex...

Ok, the minimal repro is: ``` pex.venv/bin/pex pex==2.1.99 -cpex3 -- lock create --target-system linux --target-system mac --style universal --resolver-version pip-2020-resolver jupyter-server==1.18.1 ``` Trying to lock pywinpty directly fails as you'd...

Ok, and for a Pants developer (All Pants devs have cargo installed) to easily repro, it's: ``` $ PATH=$(echo $PATH | tr : '\n' | grep -v cargo | xargs...

And it turns out in 2.1.99 with the lack of `os_name == "nt"` handling fixed y 2.1.100, the Pex lock analyzer's analysis of Pip logging is foiled leading to the...