Hi, Pants was working fine previously but now I get this error:

Failed to determine release URL for Pants: 2.23.1: pants.2.23.1-cp39-darwin_arm64.pex: URL check failed: <https://github.com/pantsbuild/pants/releases/download/release_2.23.1/pants.2.23.1-cp39-darwin_arm64.pex>: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1129)>

If this is unexpected (you are using a known good Pants version), try upgrading scie-pants first.
It may also be that the platform darwin_arm64 isn't supported for this version of Pants, or some other intermittent network/service issue.
To get help, please visit: <https://www.pantsbuild.org/community/getting-help>

I'm unsure how to solve this, I'm unsure why a self-signed certificate is being provided. I've tried upgrading

scie-pants

and have tried different pants versions with no effect. Please help!

how frustrating! sorry for the trouble. Can you think of anything that changed on your end around the time the errors started occuring?

Hi, thanks for responding! Well, I had a few virtual environments in the repo to deal with different use cases (all packages in editable mode, production mode etc,) which have been displaying weird behaviour for a while now (e.g. not showing on pip list the dependencies I can actually see when I inspect the venv etc, sometimes not deactivating properly (I.e. the path to the venv not being properly removed from PATH). I decided to try and fix this so I deleted the venvs and also tried to delete some packages that had been installed into my system python. I ran a command that also uninstalled the latest certifi version - around this time was when things stopped working. However, I reinstalled and updated certifi and cffi, (didn’t help) then downloaded the latest version of python (3.13.2) over my existing 3.13.0 installation, which also didn’t resolve the issue. I also tried things like deleting the pants local cache on my machine and other pants setup files, and reinstalling scie-pants with brew. Any ideas would be great!

https://github.com/pantsbuild/scie-pants/issues/403 may be related, there's suggestions there about setting

SSL_CERT_FILE=...

somehow.

Hi again, this is related to an SSL certificate error I've been experiencing when I try to use pants that's made it impossible to use it for the past month. I've tried your suggestion above and a lot of other things, but it's not fixed the issue 😕 if you have any idea of other things I haven't already tried that would be really helpful, as right now I'm out of ideas. I uninstalled all python versions on my machine and reinstalled versions 3.12 and 3.13 with pyenv, I reinstalled ssl@v3 with brew, tried different pants versions, upgrading scie-pants, etc. Any help would be great!

Do you have

openssl

as a tool? If so

openssl s_client -showcerts -connect <http://github.com:443|github.com:443>

should dump the whole chain etc.

Hi, the openssl command helped me realise that my organisation has started forwarding traffic through a proxy and pants wasn't able to trust the certificate. I found this guide on the pants site, which was helpful, though I did also learn that the

ca_certs_path

variable in

pants.toml

doesn't work consistently if there are spaces in the file path to the created CA bundle as it seems there's one task that needs the whitespace character to be escaped, and another that requires it not to be! It's working now, thanks for your debugging help. I'll chalk this one up to the corporate spyware. Thanks for your help!

Glad we found the root cause! IT departments, eh? Though I'm curious about this:

doesn't work consistently if there are spaces in the file path to the created CA bundle as it seems there's one task that needs the whitespace character to be escaped

Do you mean Pants does something wrong if the path has embedded whitespace? That seems worthy of an issue, from our POV it should just be a string, no need for escaping.

It seems to fail to find the path if it includes whitespace. When I moved from

/Library/Application Support/...

to

/Users/max/...(no spaces)

it started to work, though perhaps there are other quirks in the process I haven't considered.