I use proxy to speed up the connection to github.com with shell proxy settings: export https_proxy=http://127.0.0.1:6152;export http_proxy=http://127.0.0.1:6152;export all_proxy=socks5://127.0.0.1:6153
Normally I get only 50 KiB/s without proxy. The HTTPS proxy could boost the dependencies resolving speed up to 8 MiB/s. However, the Xcode does not follow the shell proxy settings neither the system proxy settings.
The Vapor 3 toolbox supports vapor xcode command to resolve SwiftPM under the shell and generate a project for editing. But in the Vapor 4 that command alias to open package.swift. That's a pain for me.
I wonder if there is an entry to set the proxy for Xcode to resolve the SwiftPM dependencies.
However, I think the Xcode GUI uses its own environment with a clean slate. A command line build with xcodebuild does inherit the shell environment, so maybe if you do that first it will inherit your proxy? Then after it is resolved you can switch to the GUI until the next time you need to update the pins?
Yeah, if you can replicate anything from the command line and then get it into the GUI it works, but it’s not ideal. Especially for those of us behind a corporate proxy, where it’s the only way to do git operations at all.
I did a little experiment. I opened up a shell, set an environment variable, then used the 'open' command:
open -a Xcode.app
I a created a test command line app, and added a run-script phase that simply used 'printenv' (tcsh shell, there is an equivalent for bash, zsh, may even be printenv). That environment variable was in the list. I then closed out Xcode, and re-started it by double clicking. Opened the same project, cleaned the build folder, and re-built the project. Looking at the list, the environment value was not there. So, you might get away with using the "open Xcode.app" in a shell to get your proxies to work.
I think Xcode uses whatever environment has been setup when it's invoked. If you open it by double clicking, it's running the in the WindowServer process, which inherits the environment from launchd, the top-most daemon on MacOS. That's a pretty minimal environment. There are ways you can add environment variables to the launchd environment, but, it is more esoteric than it used to be. Opening Xcode using the 'open' command in the shell inherits the environment of that shell instance.
Yep, this is right, the system provider is basically like shelling out to git, so everything that would work when using git on the CLI should also work in this mode.
In 12.5, the system provider is actually the default when using xcodebuild since aligning with git makes sense for things like CI systems.
This is glorious. My company does SSL inspection that seems to muck with SPM some of time because of the certificate resigning. Git in a terminal is fine and always works (with the right settings). The solution offered by @grigorye definitely helps for doing the package resolution/updates. Just curious - with the change in 12.5 mentioned by @NeoNacho, does that mean that the Xcode app will also be using the system provider settings? I mean, it's all xcodebuild under the hood anyways.
It seems like our company does the same (inspection). Is there any way to see what Xcode is actually trying to do when it tries to connect and whether it uses some proxy settings or not?