You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NO_PROXY env var disables configured proxies globally #425
When HTTPS_PROXY is configured, setting NO_PROXY for specific hosts makes PyManager bypass the proxy for every request. This breaks downloads in networks that require a proxy.
NO_PROXY should bypass the proxy only for matching destinations, commonly local or private network addresses; other requests should continue using the configured proxy.
Since it's already an override for your system settings, I'm going to label this as a potential enhancement, not a bug. We assume that the system settings are global and the environment variables are local overrides, set specifically for running the install manager, and so you shouldn't need to override your own custom configuration (just fix the configuration).
But if it's possible to flow through a per-destination proxy setting, then we can do it. Since we mostly outsource redirect handling to the OS though, I suspect it'll have limitations.
I'm in a corporate environment that sets HTTP_PROXY / HTTPS_PROXY / NO_PROXY for me, so it's not being used as a local override.
The NO_PROXY behavior @AlecJY describes is a convention probably originating from curl, whereas pymanager seems to be just using it as an override flag. I expect not following convention is going to continue to cause headaches.
If you do nothing else, at least drop support for NO_PROXY.
I expect not following convention is going to continue to cause headaches.
Well, apparently following a convention is also causing headaches. There's a reason I left these out in the initial design and only added them because someone contributed it 😉
Probably the best option here would be to switch the three variables into configuration settings that default to the variables (essentially, "NO_PROXY": "%NO_PROXY%" in the pymanager.json for each). Then you could define your own config file to override them and make them blank, so the variable is ignored. Would that be a workable approach?
Also, how does curl work in your environment? Or do you all just work around it by using a different tool? (I'm trying to get a feel for how correct/incorrect your corporate environment setup is.)
Speaking strictly as somebody who is aware my environment has these variables, have already worked out how pymanager is interpreting these variables, and has the patience to fiddle with config files, that sounds like a workable approach to me.
Testing both these binaries: "C:\Windows\System32\curl.exe" (v 8.13.0, bundled with Windows), and "C:\Program Files\Git\mingw64\bin\curl.exe" (v 8.21.0, bundled with Git for Windows)
And testing with these environment variables set: HTTP_PROXY, HTTPS_PROXY, NO_PROXY -- where NO_PROXY is set to "localhost,myemployername.com,127.0.0.1"
But what if you also clear HTTP_PROXY and HTTPS_PROXY? In that case, on a properly configured Windows machine, I'd expect the OS settings to be followed and everything to work (assuming the OS settings are correct).
If you can set/unset one of those variables, it's fair to assume you can do it for all of them.
So what remains is that we need someone to define and defend1 a proper specification for how these variables are meant to actually work. And then implement it, test it, and support it.
Footnotes
Since last time we only required someone to define the spec, and now I'm left having to defend something that I don't use, know about, or frankly care to worry about. ↩
Activity
zooba commentedon Oct 12, 2026
Since it's already an override for your system settings, I'm going to label this as a potential enhancement, not a bug. We assume that the system settings are global and the environment variables are local overrides, set specifically for running the install manager, and so you shouldn't need to override your own custom configuration (just fix the configuration).
But if it's possible to flow through a per-destination proxy setting, then we can do it. Since we mostly outsource redirect handling to the OS though, I suspect it'll have limitations.
Tinister commentedon Oct 12, 2026
I'm in a corporate environment that sets HTTP_PROXY / HTTPS_PROXY / NO_PROXY for me, so it's not being used as a local override.
The NO_PROXY behavior @AlecJY describes is a convention probably originating from curl, whereas pymanager seems to be just using it as an override flag. I expect not following convention is going to continue to cause headaches.
If you do nothing else, at least drop support for NO_PROXY.
zooba commentedon Oct 13, 2026
Well, apparently following a convention is also causing headaches. There's a reason I left these out in the initial design and only added them because someone contributed it 😉
Probably the best option here would be to switch the three variables into configuration settings that default to the variables (essentially,
"NO_PROXY": "%NO_PROXY%"in the pymanager.json for each). Then you could define your own config file to override them and make them blank, so the variable is ignored. Would that be a workable approach?zooba commentedon Oct 13, 2026
Also, how does curl work in your environment? Or do you all just work around it by using a different tool? (I'm trying to get a feel for how correct/incorrect your corporate environment setup is.)
Tinister commentedon Oct 13, 2026
Speaking strictly as somebody who is aware my environment has these variables, have already worked out how pymanager is interpreting these variables, and has the patience to fiddle with config files, that sounds like a workable approach to me.
Tinister commentedon Oct 13, 2026
Testing both these binaries: "C:\Windows\System32\curl.exe" (v 8.13.0, bundled with Windows), and "C:\Program Files\Git\mingw64\bin\curl.exe" (v 8.21.0, bundled with Git for Windows)
And testing with these environment variables set: HTTP_PROXY, HTTPS_PROXY, NO_PROXY -- where NO_PROXY is set to "localhost,myemployername.com,127.0.0.1"
What would you have expected to happen?
zooba commentedon Oct 13, 2026
In that case, I'd expect what you set.
But what if you also clear
HTTP_PROXYandHTTPS_PROXY? In that case, on a properly configured Windows machine, I'd expect the OS settings to be followed and everything to work (assuming the OS settings are correct).If you can set/unset one of those variables, it's fair to assume you can do it for all of them.
So what remains is that we need someone to define and defend1 a proper specification for how these variables are meant to actually work. And then implement it, test it, and support it.
Footnotes
Since last time we only required someone to define the spec, and now I'm left having to defend something that I don't use, know about, or frankly care to worry about. ↩