[swift-build-dev] [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

[Paul Cantrell]

Just a quick mini-review here; sorry, time pressure.

This version of the proposal seems acceptable to me, though I have a nagging feel that it’s more complex than it needs to be.

In particular, the two modes (autopin enabled / disabled) plus the --repin option seem to me to have a high confusion:benefit ratio. I can imagine a much simpler model in which:

general behavior is always like --enable-autopin,
update always acts as if --repin is specified, and
.gitignore is the sole difference in how pinning behaves for different projects.

What is the benefit of the proposal’s more complex model? AFAICT, the one thing this simpler model wouldn’t allow is for a team to share pinned versions of some individual ill-behaved dependencies without pinning all of them. If that’s the only missing behavior, my gut tells me there’s a way to do that with less cognitive burden on SwiftPM users. (Are there other benefits to the proposal’s model that I’m missing?)

Those concerns stated, I’d be fine with the proposal as stated. It would accommodate all the different ways I can imagine using SwiftPM on my own projects. It might be confusing to newcomers, but it won’t be a roadblock for getting work done.

Cheers,

Paul


> On Nov 19, 2016, at 11:48 PM, Anders Bertelrud via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0145: Package Manager Version Pinning" begins again after revisions, starting now and running through November 28th. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at
> 
> 	https://lists.swift.org/mailman/listinfo/swift-build-dev
> 	https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> Anders Bertelrud
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161128/18c96c55/attachment.html>