pass important env variable for proxy support in pip

[Stefano Sinigardi (cenit)]

as per title

[Kai Pastor (dg0yt)]

So we can fix online builds, but we still can't build offline when it comes to pip an friends.

[Billy O'Neal (BillyONeal)]

Can you point to docs for these and/or what the customer expectation for them is? In general we should be trying to route this stuff through x-download although it's understandable we might be unable to do so for pip.

To be clear, my concern would be customers expecting these variables to control other vcpkg downloads unrelated to pip and they not doing so, for instance, if we select the WinHTTP backend.

[Stefano Sinigardi (cenit)]

https://pip.pypa.io/en/stable/topics/https-certificates/

you mean something like this?
the problem is that unless you have the very very recent pip 24.2+ coupled with a recent python interpreter already installed (not the case for vcpkg python tooling), corporate proxies are not supported without these env variables defined. But if you have your variables defined and you expect to make them enable vcpkg python tooling, you are welcomed with an error since vcpkg masks most of the env variables

[Billy O'Neal (BillyONeal)]

But if you have your variables defined and you expect to make them enable vcpkg python tooling, you are welcomed with an error since vcpkg masks most of the env variables

Would it make sense for folks in this situation to opt-in to it by using VCPKG_KEEP_ENV_VARS?

[Stefano Sinigardi (cenit)]

is there any rule written anywhere to say what should pass always if defined and what not and the user has to opt-in?
this env variable is not modifying the build but just enabling tools to work in specific environments

[Billy O'Neal (BillyONeal)]

is there any rule written anywhere to say what should pass always if defined and what not and the user has to opt-in? this env variable is not modifying the build but just enabling tools to work in specific environments

The problem is that it's enabling a pattern that we are kinda trying to intentionally prevent (downloading things without going through asset caching) and we are concerned that adding such workarounds to the tool condones the behavior.

[Stefano Sinigardi (cenit)]

understood. I just reply with consistency with curl treatment (http_proxy and https_proxy env variables), but then I'll just leave the field and pip has to survive by itself 😄

[Billy O'Neal (BillyONeal)]

I just reply with consistency with curl treatment (http_proxy and https_proxy env variables)

I think I missed something here. Are you saying that libcurl listens to those variables too and we should pass them to it as well? (That is, this would improve 'correct' calls of x-download as well as the 'problematic' calls from pip?)