I am running into an issue using the bleeding edge...
# development
e
I am running into an issue using the bleeding edge 2.11.0rc0. When I do a reset of pants cache and pants.d and set python to
python>=3.8
and
.python-version
has 3.8.13 set, I get an error saying the SHA256 of
pex
is not as expected. I also have pex-cli.url_template set to a local path because I'm behind an aggressive proxy. If I set python to 3.9 it works. I can also revert to 3.8 and it will continue to work. The prerequisites for 2.11 says 3.7, 3.8 or 3.9 required.
Are the docs correct?
Seems like a more user friendly error message is needed if this is a user error.
If it is 2.11 issue, I can try to reproduce it on my home machine where I can provide more verbose logs.
I suspect it is an issue with the hash check.
w
what’s the error message?
is it coming from the
pants
script, or post bootstrap?
if the error is anything like this one, then a fix might already be in flight: https://github.com/pantsbuild/pex/issues/1683 … but the a sha check for PEX itself seems more likely to be related to the
pants
script itself, which downloads PEX: https://github.com/pantsbuild/setup/blob/e7868493e783174be993cc8b3dd0ed453c83e6f6/pants#L37-L39
e
I am not on my machine to confirm, but it happens before the pex download so is probably the
pants
script.
w
Ok, yea. Would make sure you have the latest version of the script: if that doesn't help, then filing an issue on that repo would be helpful. Thanks a lot!
and/or modifying the script to report the actual difference between the files
e
I will update the script and try again. I have to manually download
pex
in my environment and have a setting in
pants.toml
for that. My quick glance at the script and all the hard coded hashes in there, I suspect it isn't using my manual download location. The
pex
file being downloaded probably is just a text file saying, “nope.”
But that doesn't make sense because I am able to get it working at some point. Maybe it's a bootstrap race condition (if the
pants
script is out of sync with the version…). I'm just speculating at this point. I think my theory that the proxy is messing things up must be wrong if I am able to get past the bootstrap step before updating the version.
I started with a released version then moved to the 2.11.0.dev0 version and on up the chain with latest releases. I didn't reset my cache et al until the rc0 release.