Reviews are an important part of the Swift evolution process. All reviews should be made in this thread on the Swift forums or, if you would like to keep your feedback private, directly in email to me as the review manager.
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 the Swift Package Manager?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages, libraries, or package managers 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?
Positive: I believe this proposal adds useful functionality to Swift Package Manager.
Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
Yes. It is not uncommon in both development and usage to want to work on temporary (or permanent) forks of repositories. In the absence of this change, doing so requires recursively editing all Package.swift files that depend on that repository, or creating some kind of intercepting live proxy to capture all the git clones. This approach is substantial simpler.
Does this proposal fit well with the feel and direction of Swift?
I believe so.
If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?
My experience is only with package managers that have package indices. When using a package index, mirroring a package can be more easily achieved by creating local proxy or delegating package indices. This is obviously not a workable solution in the absence of a Swift Package Index. If such a package index ever comes into existence this feature should be revisited.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading of this posting, plus substantial study of the initial proposal.
Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
Yes, this seems like a very useful and important feature for development of Swift packages.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?
I haven't worked with another package manager with similar mechanisms.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading of the proposal.
After reading the proposal, I'm left with a few questions.
Will there be a way to read values from the config? The proposal only mentions setting and unsetting.
Will the format of the config file be documented/supported? The proposal mentions that it will be JSON, but doesn't give any details.
Was a file format and command structure like git config considered?
I think it's important to expose read interfaces to the configuration. This can be important for other tooling, and I don't think tools should be required to use SwiftPM as a library in order to read them.
I also think it would be a good idea to consider the configuration format first and separately (as a separate proposal).
I agree we should provide commands to read the config file as well. @NeoNacho suggested a get-mirror command.
The format of the configuration file will be an implementation detail, at least for now.
I discussed this with some other developers when I was writing the proposal. Currently, we don't have a lot of use-cases for the config file in SwiftPM. It will be difficult to write a proposal without having at least some concrete ideas. However, we're starting with something very simple and it can be expanded (with a proposal) in future, once we have more use-cases for it.
$ swift package config get-mirror \
--package-url https://github.com/Core/libCore.git
https://mygithub.com/myOrg/libCore.git
It might also be interesting to have a general swift package config get-mirror command which lists all configured mirrors, but there's the question of the output format.
The review of SE-0219 “Package Manager Dependency Mirroring" ran from July 10…17. Feedback was positive, and the proposal is accepted with revisions (adding a swift package config get-mirror command). Thanks to everyone who participated!