Timout question. Our private wheel repository is o...
# general
j
Timout question. Our private wheel repository is only available while on a VPN. I just noticed a
./pants binary
run going for over 1000+ seconds with no sign of stopping because my VPN had dropped. Is there a way to set a timeout for the "Resolving requirements" stage?
a
hm. setting
PEX_HTTP_TIMEOUT
should work, but it also says the default is 15. it also requires that pex be built with the
requests
library for this to work, but i would assume we do that for the pex versions we use in pants. i will see whether we override that anywhere in pants
👍🏽 1
j
Also, there were 25 requirements. Does it fail on the first, then fail on the second, etc, before giving an error? Ideally what I would want is to add a "Can I reach the repo?" step before starting to resolve. Is this possible?
a
it should invoke pip on all requirements at once, and pip should fail fast, so this is a very weird failure mode
j
I just ran with
EX_HTTP_TIMEOUT=15 ./v2 binary
and it failed earlier. Longer then 15 seconds. The error message is also cryptic:
Cython>=0.22 and NumPy are required.
Let me see if
--print-exception-stacktrace
has more info...
👍🏻 1
a
hm. could i ask you to please file a pants issue at https://github.com/pantsbuild/issues/new with: - the pants version you're using - the full pants command line - the full output (with
--print-exception-stacktrace
as you mentioned)
just so we can have it all in one place
j
Will do.
It is 1.30.1 for the slack record.
👌🏻 1
a
thank you!
a
omg sorry, i meant against the pants repo
👖 1
because i'm not sure whether this was something pants was doing and i only asked in #pex because i had a hunch
j
Someday the browsers will read our minds and we will be able to code in YadaYada.
a
possibly!! but even just using firefox it will complete addresses ridiculously nicely so i might have been relying on that lol
🦊 1
🔥 1
oh! it looks like pex 2.1.10 dropped those env vars
and we would have to pass
--retries
and/or
--timeout
on the command line we generate in pants
if you make the issue, i can post that as a comment
j
a
thank you!
j
pants
doesn't recognize those flags. Do I need to add them after the whole line and a
--
? Or is this something that needs to be added at the
pex
stage?
a
this would need to be modified inside of pants i think
👍🏽 1
j
Workaround: look at my running build output more often and make more sacrifices to the VPN gods
a
ugh!!!! sorry
we can fix this, that's exactly what i want pants to fix
j
No apology necessary! It is not wrong to assume that there is a network. But we will all get burned 🔥 by that assumption at some point.
And yes, a fix would be appreciated. 😄
It would be cool if
pants
had a
pre-run
,
post-run
feature. When our repo was running v1.18, we used a lot of shell wrapper scripts. This would be an example of where I would write a script that verifies access to the wheel repo and then kick off
./pants binary
build. If pants had a
.pre-run.d/
feature, I could just drop a script in there that verifies I have network connectivity to the wheel repo. When it returns 0, the
pants
run continues, if it returns
1
then it would error out with a message from the script.
Hmm.. This would probably have to be something done per goal.
😕
complexity.
a
so we absolutely support and encourage pants wrapper scripts! this is part of why we continue to make
./pants
itself a script instead of a larger pex file. at what point would you want the pre-run scripts to run? just before pants itself? or after some part of pants?
j
For the use case of "am I on VPN so I can do things with pants?" I would want that to run before pants itself.
When we ran v1.18 we had a highly customized version of
pants
(the bash script). Maybe this script could be modified to look in a
.pants.d/pre-pants
directory and source the scripts if finds there. Then people could customize
pants
without having to modify it. This could potentially make upgrading easier when the
pants
script itself changes.
I'll make a feature request issue for that so the idea can be improved or booted.
a
yes! and if someone responds by closing the issue, feel free to respond further if you think you can respond to their concerns
j
Oh wait. There i something about this already in the script. WRAPPER. Let me see if that already covers my use case.
haha. Wait I am already doing this with the
v2
script. Duh. I can just modify that to do what I want. and I think that's a more 👖 way to go for the community. (i.e. I think I can get developers onboard with running
v2 blah
when we make the jump to 2.0.0). Putting this kind of logic into the official
pants
script will just increase its complexity. Having a community policy of supporting wrapping the
pants
script solves the issue.
a
yes! this is one of the customs i think is super fantastic and unique about pants!
please let me/us know if that doesn't serve your needs though! suggestions always welcome
👍🏽 1