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.