Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review manager directly, please put "SE-0549" in the subject line.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
-1. In principle I support making proxies easier to use with SwiftPM, but I don't think this proposal is the right approach.
The proposal specifies ~/.swiftpm/configuration/proxy.json as the shared proxy location, which matches the existing SwiftPM config location on Linux but introduces inconsistency on macOS and Windows.
The primary motivation given by the proposal for supporting a config file in addition to environment variables is use in Xcode, which is outside the scope of the evolution process.
The proposal specifies that SwiftPM proxy configuration does not impact git operations (which continue to respect only env vars). In practice I think this prevents nearly all users from adopting the config file today given most existing packages rely on git to resolve dependencies.
The proposal specifies too many implementation details for a typical evolution document and ties SwiftPM to Foundation's URLSession for all networking, including prescribing use of specific CF constants like `kCFNetworkProxiesHTTPEnable`. It's relatively likely SwiftPM will want to adopt NIO and/or API proposed under the networking vision in the future, and we shouldn't close off that possibility.
I agree with Owen here. MacOS, Linux and Windows support either environment variables or setting up the http proxy using their native Settings app. We should make sure those work with SwiftPM.
Thanks @owenv and Doug for the follow-up. I agree that several parts of the proposal need clarification, but I believe the environment and file-based mechanisms serve complementary purposes.
The shared path should be SwiftPM’s existing platform-specific shared configuration directory, rather than universally ~/.swiftpm/configuration. That path was intended as an example. The implementation already obtains the global directory through SwiftPM’s swiftPMConfigurationDirectory; I will correct the proposal and its examples.
I agree that this proposal cannot specify Xcode behavior, but I do not think that makes the motivating use case out of scope. The proposed behavior belongs entirely to SwiftPM: SwiftPM gains a persistent configuration source that does not depend on its process environment. Xcode is one concrete example of a client that invokes SwiftPM without the user’s shell environment; no Xcode integration or behavior is being proposed.
Regarding Git, environment variables remain the highest-priority and simplest configuration mechanism. They already reach Git subprocesses, and this proposal makes SwiftPM’s own HTTP operations honor the same values. This gives CLI and CI users one configuration path for both.
proxy.json serves a separate purpose: persistent SwiftPM configuration when environment variables are unavailable. It is not intended to replace Git’s existing proxy support through environment variables or gitconfig. For example, the motivating failure occurs when Git dependencies resolve successfully but a binary target download performed by SwiftPM’s HTTP client fails. The fact that Git already supports proxies does not remove that gap. I will make this division of responsibility clearer in the proposal. The proposal also intends to preserve native proxy behavior as a fallback, rather than replace it.
Finally, I agree that the evolution document should describe observable behavior, precedence, and scope without prescribing URLSession, connectionProxyDictionary, or specific CoreFoundation constants. I will rewrite that section so future networking implementations such as NIO remain possible.
Since the review closes today and these clarifications require proposal edits, @FranzBusch, would you be open to a short extension so the updated text can be reviewed?
It keeps both environment-variable and proxy.json support while clarifying the platform-specific path, Xcode’s role as motivation, Git configuration, native proxy fallback, and backend-neutral requirements. This gives reviewers a concrete revision to evaluate while the extension request is considered. Thanks!