<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I have implemented the revisions to SE-0145 to support automatic pinning.<div class=""><br class=""></div><div class="">The approach we took was to leave much of the existing behaviors, but to support an "automatic pinning" mode which is then on by default.</div><div class=""><br class=""></div><div class="">If anyone wants to provide early feedback, my draft is here:</div><div class=""> <a href="https://github.com/ddunbar/swift-evolution/blob/automatic-pinning/proposals/0145-package-manager-version-pinning.md" class="">https://github.com/ddunbar/swift-evolution/blob/automatic-pinning/proposals/0145-package-manager-version-pinning.md</a></div><div class=""><br class=""></div><div class="">Otherwise I intend to take this to review again as soon as I hear from other team members.</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 11, 2016, at 11:46 AM, Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com" class="">daniel_dunbar@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2016, at 9:28 AM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks for being open to feedback, Daniel, even when it’s difficult feedback. :)</div><div class=""><br class=""></div><div class="">Pondering #2: is there a behavioral difference between</div><div class=""><br class=""></div><div class="">1. explicit “do not pin” option in SwiftPM and</div><div class="">2. Package.pins added to .gitignore?</div><div class=""><br class=""></div><div class="">(In #2, individual ill-behaved packages would be version-pinned in Package.swift.)</div><div class=""><br class=""></div><div class="">I imagine that the effect of #1 moves version pinning from Package.pins to some local hidden/internal location that isn’t shared across machines. That sounds to me like “there is always a pinfile, it always works the same way, but sometimes teams choose not to share it across machines” — which sounds a lot like #2. But maybe it’s more subtle than that?</div></div></div></blockquote><div class=""><br class=""></div>I think the behavior difference comes in in how individual commands like `swift package update` behave and what their diagnostics are.</div><div class=""><br class=""></div><div class="">I want it to be possible for developers to, for example, maintain individual pins but not auto-pin everything else (and even potentially check in that configuration).</div><div class=""><br class=""></div><div class="">Hoping to have a concrete proposal written up shortly...</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""></blockquote></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2016, at 11:41 AM, Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com" class="">daniel_dunbar@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks to everyone who participated in this review!<div class=""><br class=""></div><div class="">Based on the pretty universal negative feedback, we are going to reject this proposal as is, and take it back for another round of revisions.</div><div class=""><br class=""></div><div class="">Our revised plan is:</div><div class="">1. To introduce an "autopin" behavior to cover the problem Paul outlined where `pin --all` effectively needs to be "sticky" for any new dependencies which come into play.</div><div class="">2. To make auto pinning on by default, with an explicit mechanism for projects to opt out.</div><div class=""><br class=""></div><div class="">I hope to have this written up for review next week.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""> - Daniel</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 4, 2016, at 9:06 AM, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="" style="font-size: 14px;"><b class="">What is your evaluation of the proposal?</b></span><br class=""><br class=""></div><div class="">General +1, with reservations. Novel elements of the proposed behavior will need careful evaluation and refinement as we see how they plays out in practice, with open-mindedness from both users and the core team.</div><div class=""><br class=""></div><div class="">Breaking it down:</div><div class=""><br class=""></div><div class="">+1 on having this feature in some form. It’s essential.</div><div class=""><br class=""></div><div class="">+1 on making user choice about .gitignore the thing that controls whether and how pinning is shared within a team. That’s simple, clear, accommodates a wide range of needs, and is consistent with other package managers.</div><div class=""><br class=""></div><div class="">+1 that pinfiles have no effect whatsoever on dependent projects. That’s the only sensible way for it to work, but since there was some debate about that, I’ll just reiterate support.</div><div class=""><br class=""></div><div class="">-1 on making dependencies unpinned by default. Trying to induce unexpected behavior to encourage testing can be a good technique — in contexts where <i class="">testing is the goal</i>. My gut tells me that doing this when <i class="">building</i> is the goal will cause a lot of confusion and kvetching. I follow the proposal’s argument that unexpected breakages are a nice way to make strict semver a community norm … and I just do not buy it.</div><div class=""><br class=""></div><div class="">However, given that we hashed this out at great length and the core team is still enamored of the idea, I’m willing to give it a try! I’d love to be proved wrong.</div><div class=""><br class=""></div><div class="">+1 on the proposed command structure given that I’ve lost the aforementioned “always pin” argument. Living in a sometimes-pinned-sometimes-not world is going to be confusing, but the proposed commands help as best they can.</div><div class=""><br class=""></div><div class="">¿-1? This is a big one. If I do:</div><div class=""><br class=""></div><div class=""> swift package pin --all</div><div class=""><br class=""></div><div class="">…and then add a new dependency, is the new dependency also pinned? It should be. To pin or not to pin is <i class="">typically</i> a project- and team-wide policy decision. I do see the use case for pinning just one ill-behaved dependency, but more typically pinning is something that is built in to a team’s testing process and their assumptions about a whole build’s behavior.</div><div class=""><br class=""></div><div class="">The proposal is vague on this point, but could be interpreted to mean that --all does not pin new dependencies: “Dependencies are never automatically pinned, pinning is only ever taken as a result of an explicit user action.” (Aside: there should be a semicolon instead of a comma in that sentence.) I assume — hope — that this is not the case! <b class="">If --all does not affect new dependencies</b>, then I’m -1 on the proposal.</div><div class=""><br class=""></div><div class="">¿-1? The proposal mentions that SwiftPM already effectively performs local pinning, but is ambiguous about whether this behavior remains separate from the new pinfile. I’m dubious about having two separate pinning mechanisms, one visible and one invisible.</div><div class=""><br class=""></div><div class="">+1 to the proposal’s repeated mentions of clear output and helpful diagnostics. Since this proposal introduces behavior that’s somewhat off the beaten path for package managers, this will be essential.</div><div class=""><br class=""></div><div class=""><b class="">On the pin/lock controversy</b></div><div class=""><br class=""></div><div class="">I don’t care. Computer science is full of heavily overloaded terms where a loose underlying concept takes on radically different meanings (bridge, channel, dispatch, edge, graph, header, key, model, module, node, open, parameter, port, process, protocol, query, return, row, source, union). We do just fine disambiguating all these in context, thank you very much. Renaming “lock” to “pin” solves a problem that doesn’t exist.</div><div class=""><br class=""></div><div class="">However, we programmers are _also_ used to dealing with synonyms or partially overlapping near-synonyms (nil / null; closure / lambda / block; field / instance variable; tagged union / associated type enum; etc) and we also do just fine with those too. I’m sure we’ll learn to deal with lock / pin, and nobody will care after 6 months.</div><div class=""><br class=""></div><div class="">In short, “pin” is an unobjectionable solution to a non-problem. Core team is excited about “pin?” Grand. It’s a fine term. Do it and move on.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class=""><b class="">Is the problem being addressed significant enough to warrant a change to Swift?</b><br class=""></span><br class=""></div><div class="">It’s essential. SwiftPM will be impractical in many real-world situations until this is sorted out.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class=""><b class="">Does this proposal fit well with the feel and direction of Swift?</b><br class=""></span><br class=""></div><div class="">Yes, it’s consistent with the general approach of SwiftPM.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class=""><b class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</b><br class=""></span><br class=""></div><div class="">I’ve used bundler, Carthage, and CocoaPods extensively. All of them always generate a lockfile (Gemfile.lock, Cartfile.resolved, and Podfile.lock). All of them use these files as the unique mechanism for version locking, and all use version control of that file as the unique mechanism for controlling whether to locked versions are shared across teams.</div><div class=""><br class=""></div><div class="">We have many years of evidence that this model works well.</div><div class=""><br class=""></div><div class="">Note that all of these package managers also work in in environments that do not support using multiple versions of a dependency in the same artifact at the same time. Therefore this statement from the proposal:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Overconstraint is much more of a risk in Swift than in other languages using this style of package management.</blockquote></div><div class=""><br class=""></div><div class="">…is incorrect.</div><div class=""><br class=""></div><div class="">In particular, note that Ruby does not support using multiple versions of a lib simultaneously, and that fact alone — even in the presence of _ubiquitous_ version pinning — has been sufficient to encourage widespread mindfulness about semver compliance. All of the concerns expressed in the “Pin by default” section of the proposal also apply to Ruby, and have failed to materialize there.</div><div class=""><br class=""></div><div class="">—</div><div class=""><br class=""></div><div class="">I’ve also used npm and bower, which either do not have version locking or only provide it via add-ons. It’s a nightmare. Lack of locking has caused headaches and lost hours — not hypothetic headaches, but real ones on actual projects — in two scenarios:</div><div class=""><br class=""></div><div class="">1. onboarding new developers who get fresh, incompatible dependency versions on initial checkout; and</div><div class="">2. picking projects back up for a new round of development.</div><div class=""><br class=""></div><div class="">Are these two situations really the right time for people to accidentally test whether their dependencies have properly followed semantic versioning? No. There are better ways, and better times. I am troubled by the insistence on ignoring experience here. However, as I said above, I’m willing to give it a try. I will keep an open mind in the name of bold experimentation, and would be happy to have my concerns proven wrong.</div><div class=""><br class=""></div><div class="">Please do keep in mind, however, that this is an experiment. Be ready for all that careful theorizing to be falsified by experience. You may have to murder this darling: <a href="http://www.slate.com/blogs/browbeat/2013/10/18/_kill_your_darlings_writing_advice_what_writer_really_said_to_murder_your.html" class="">http://www.slate.com/blogs/browbeat/2013/10/18/_kill_your_darlings_writing_advice_what_writer_really_said_to_murder_your.html</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class=""><b class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b><br class=""></span></div><div class=""><br class=""></div><div class="">In depth, though I only read some of the discussion thread.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 31, 2016, at 4:23 PM, Anders Bertelrud via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="font-family: SFUIText-Regular;" class="">Hello Swift community,</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><font face="SFUIText-Regular" class="">The review of SE-0145 "Package Manager Version Pinning" begins now and runs through November 4. The proposal is available here:</font><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md</a><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: SFUIText-Regular;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">or, if you would like to keep your feedback private, directly to the review manager.</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">What goes into a review?</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">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:</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><span style="font-family: SFUIText-Regular;" class="">* What is your evaluation of the proposal?</span><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><span style="font-family: SFUIText-Regular;" class="">* Is the problem being addressed significant enough to warrant a change to Swift?</span><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><span style="font-family: SFUIText-Regular;" class="">* Does this proposal fit well with the feel and direction of Swift?</span><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><span style="font-family: SFUIText-Regular;" class="">* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><span style="font-family: SFUIText-Regular;" class="">* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">More information about the Swift evolution process is available at</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular; white-space: pre;" class="Apple-tab-span"> </span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" style="font-family: SFUIText-Regular;" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">Thank you,</span><br style="font-family: SFUIText-Regular;" class=""><br style="font-family: SFUIText-Regular;" class=""><span style="font-family: SFUIText-Regular;" class="">Anders Bertelrud</span><div class=""><span style="font-family: SFUIText-Regular;" class="">Review Manager</span><br style="font-family: SFUIText-Regular;" class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>