The second review of SE-0303: Package Manager Extensible Build Tools, begins now and runs through April 21th, 2021.
The feedback from the first review was positive, and the proposal has been amended to address the feedback provided by the community and the core team. It is now ready for a second review.
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 the review manager or direct message in the Swift forums).
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
- 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?
Thank you for helping improve the Swift programming language and ecosystem.
We are extending the review of SE-0303 until April 26 to give the community further opportunity to provide feedback.
What is your evaluation of the proposal?
+1 - it fills an important step for add extensibility to the package manager that currently requires error-prone wrappers or hacks to make work
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Allowing things like code generation, integration with linters (even if not explicit at the moment), other build tools such as gulp or webpack for server-side Swift is important for Swift as a language in my view.
Does this proposal fit well with the feel and direction of Swift?
For the most part yes. It does add a reasonable amount of complexity for the benefits, but overall the tradeoffs seem worth it. E.g. running a simple script (Swift or otherwise) before the rest the of code build is complicated (from my understanding) instead of pointing it at a file in the same package. However the complexity provides much greater flexibility for running other tools.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read through the proposal a few times
Finally getting a chance to skim through things.
The proposal mentions:
let commandConstructor: BuildCommandConstructor
But I don't see a definition for
BuildCommandConstructor, just the
In the examples, the
plugin.swift and parent directory seems to be under
Sources, but other parts of the proposal seems to say things should be in
Plugins instead of
Thanks for pointing out these mistakes! That declaration is indeed wrong, but the protocol itself is correct. I'll be sure to correct these mistakes when/if the proposal is accepted.