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 DM. When contacting the review manager directly, please put "SE-0511" in the subject line.
Trying it out
If you'd like to try this proposal out, you can download a toolchain supporting it: add links here
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:
This looks great to me. I find the command-line interface for updating the package manifest to be much easier to get right, and have needed this for plugins.
A big +1 from me. I think it's a logical extension to what we added earlier to add dependencies and target dependencies using a command line invocation, which makes describing how to get a Swift package enabled for an arbitrary project much easier to wrangle than replicating the internal Package.swift structure narratively describing it out. This adds it for plugins, equally as relevant.
I (personally) wish that even now, as a project, we might reconsider Package.swift from doing this tools-version focused "interpreted" Swift code to instead use something more clearly a data-focused declaration. I think that would greatly simplify and remove a number of the workarounds that have come into being with changing structure based on environment variables workarounds, conditional compilation based on platform, etc - but if or until that were to ever happen, being able to get this kind of capability with these commands and the AST wrangling to append in structures is great.
I do wonder if we need a larger vision in place to make sure these package manifest edit commands are consistent with each other as we add them one by one. In theory, every model element in the manifest model could use one of these.
+1, I think this is a nice uncontroversial improvement to the manifest editing commands.
Is the problem being addressed significant enough to warrant a change to Swift?
I think so - in combination with the add-dependency command it makes it easy to get up and running integrating a new package plugin vended by some other package.
Does this proposal fit well with the feel and direction of Swift?
Yes, the CLI interface is consistent with the existing commands and this closes a gap in existing functionality.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
