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

[Daniel Dunbar]

> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

I agree with this feeling, but am not sure how much it will matter in practice.

> 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?)

This is a benefit I *really* want to retain, because we continue to feel it is important for people not to overly constraint the dependency graph, and I still feel this is the right model for users to follow (pin problematic dependencies, not everything). I really want to retain the technical ability to do it, even if it is off by default.

If you have a concrete proposal on a better way to implement this I would love to hear it.

> 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.

At this point, what I want to do is get this implemented and in a usable state, and then gauge how problematic this behavior difference is. If it is a source of confusion, then we should iterate to try and address it.

 - Daniel

> 
> Cheers,
> 
> Paul
> 
> 
>> On Nov 19, 2016, at 11:48 PM, Anders Bertelrud via swift-evolution <swift-evolution at swift.org <mailto: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 <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
> 
> _______________________________________________
> 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/20161202/97846bb7/attachment.html>