https://pantsbuild.org/ logo
Join Slack
Powered by
After much debugging, figured out the issue with p...
# general
b
After much debugging, figured out the issue with ptex not being able to download through a proxy. But even after resolving, it seems pants can't. So the issue now is this: I have the linter set to ruff. Pants lint :: tries to download ruff. It can't download (shows downloading with a timer, but no progress). If I take the url and run ptex -D url > foo.tar.gz Then it successfully downloads. This is different to my prior issue where pants was failing to bootstrap. Now it's around pants downloading ruff.
f
Is there anything useful in the debug output? Somewhat related use case to https://github.com/pantsbuild/pants/issues/21964 But from your other messages, it sounds like you're getting a redirect?
b
Print stack trace a ldebug don't give any more info. Gets to downloading and the timer keeps ticking. I think all github downloads redirect, and that issue seems resolved as ptex from the cli seems to download from the same url that pants is trying.
e
could it be a certificate issue? running from the cli picks up whatever system certs and stuff are available, but when its done by pants there is enough sandboxing that the custom corp/proxy certs don't get used?
b
Possible. I think SSL_CERT_FILE and SSL_CERT_DIR are automatically passed, right? Anything I can do to check? I unset those env vars and ptex can still download.
Would even be happy to disable cert checks.
Looks like it's not limited to ruff. Pants run fails trying to download pex as well. Well... Doesn't fail... Just endless timer.
Is there a way to print out env vars pants is using?
f
Just endless timer
What pants version are you on? There was this fix in 2.26 for an extremely long exp backoff calculation https://github.com/pantsbuild/pants/pull/21959
b
I've tried with 2.28.0.dev1 and dev 2.
Damn... 2.26.0 works. Guess I should report a regression!
f
interesting, mind trying some versions inbetween to find the first occurance?
b
Yeah... Doing it now.
2.27.0rc0 doesn't work.
2.26.1rc0 works
2.28.0.dev0 doesn't work.
2.27.0a0 doesn't work.
2.27.0dev3 doesn't work.
2.27.0dev0 works
2.27.0dev1 works
2.27.0dev2 works
So looks like it was introduced in 2.27.0dev3.
f
Nothing obvious to me in there, except maybe the ruff upgrade? I think if the byte length is wrong it might hang in a way you described. Can you try forcing the older version of ruff? (its an option you can pass)
b
It's not just ruff though. Pants run fails trying to download pex as well.
f
ah ok
though there is a pex upgrade there too
what os / arch are you on?
b
Amazon Linux 2023
X64
@fresh-mechanic-68429 can you please point me to how I can force the version of ruff? Can try it out.
f
https://www.pantsbuild.org/stable/reference/subsystems/ruff#version set that to 
0.11.0
which was the older default (
0.11.5
is the new one)
b
Tried it. Same as before.
f
Worth running from source and trying to isolate the exact commit that is causing issues. Absent that we'll a way to reproduce (I don't have a proxy setup)
b
Will give it a shot later and report back. Time to break out the old bisect.
Trying to run pants from source to find the offending commit. It gets to building native code... Fails to download channel-rust-1.86.0.toml.sha256 from static.rust-lang.org. Source TimedOut. I can curl the url though. Seems like Reqwest isn't passing the proxy vars. Anything I can do to force it?
e
Not sure if this affects native code sections, but I've got
Copy code
[subprocess-environment]
env_vars.add = [
    "http_proxy",
    "https_proxy",
    "no_proxy",
    "HTTP_PROXY",
    "HTTPS_PROXY",
    "NO_PROXY",
]
in my 
.pants.rc
file. Does a config like this work for you?
b
Interesting.... It's failing on cargo build --features=extension-module --release -p engine -p client from inside src/rust/engine. But then if I cd a terminal into the folder and run the command, then it doesn't fail to download. Trying with the subprocess thing.
Actually... I can easily print out the env vars and see if they're passed or not.
Hmm... Well cd-ind and running cargo build worked. But also, running from the pants script, I can see the http_proxy variable is set. Wonder why it couldn't download from there. At least, got a very manual build process working. Gotta love proxies!
(http_proxy var is available at the point exec cargo $@ is called. This is without setting subprocess env values)
When running from source from another project (eg PANTS_SOURCE=.. /../pants pants lint ::), where does ruff get downloaded to by default?
OK... Running into some caching issues trying to test this. 1. Rm - rf ~/.cache/pants 2. Run pants lint (not from source) for 2.28.0.dev2. Fails to download ruff. 3. PANTS_SOURCE=.. /.. /pants pants lint :: with release_2.28.0.dev2 checked out in the source dir. Downloads ruff successfully and lints. 4. Run pants lint :: without PANTS_SOURCE. runs fine. 5. Clear ~/.cache/pants, without source fails. I'm guessing the source run is downloading and the cached version is being picked up. What directory can I clear to ensure ruff is definitely downloaded?
Also, I created the issue in scie-pants, but should I move it to pants? Seems to be the pants release that broke the download stuff.
f
I think its downloaded to 
~/.cache/pants/lmdb_store
, but I'm not sure which subdirectory
b
Hmm... So it looks like it's downloading successfully when running from source checked out at the release commit, but not from the released version. I should add that I had to run cargo build in the src/rust/engine from my terminal. When running pants from source it failed to build the cargo build as it was failing to download stuff.
18 Views
Open in Slack
PreviousNext
Powered by