<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Oct 2016, at 18:55, Daniel Dunbar via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 14, 2016, at 9:43 AM, Alexis via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></blockquote></div></div></div></blockquote></div></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span style="font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">We considered making the pinning behavior default on running </span><code class="" style="font-size: 14px; -webkit-print-color-adjust: exact; margin: 0px 2px; padding: 0px 5px; white-space: nowrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">swift build</code><span style="font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">, however we think that pinning by default is likely to make the package graph more constrained than it should be. It drives the user away from taking full advantage of semantic versioning. We think it will be good for the package ecosystem if such a restriction is not the default behavior and that this design will lead to faster discovery of bugs and fixes in the upstream.</span></blockquote></blockquote></blockquote><blockquote type="cite" 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=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div>I agree with the others that this is the better solution.<br class=""><div class=""><br class=""></div><div class="">With regards to the constraining problem, the key insight adopted by Cargo/Yarn/Bundler is to distinguish libraries from applications. A library shouldn’t pin its dependencies, while an application should. This ensures that the ecosystem itself is maximally unconstrained, while ensuring actual applications continue to reliably build, regardless of ecosystem changes and the computer that it was built on. If a version of a library has trouble building with different versions, it should ideally specify that with its dependency constraints, not a lock file.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This I think is one big crux of the current discussion, and one of the things not in the proposal was my expectation that most packages right now are going to be shared (I personally wouldn't say libraries vs applications, since applications can also be shared as build tools, I think it comes down to whether it is shared or not).</div><div class=""><br class=""></div><div class="">If we agree that a library shouldn't pin its dependencies, how would you surface this feature? What exact behavior would you prefer?</div><div class=""><br class=""></div></div></div></blockquote><div><div><div><br class=""></div><div>Bundler, Composer, Cargo & Yarn all ignore the lock file on dependencies and only use the one on the main build target so that they can solve the constraining problem. The final build target lock file does have the list of all exact version required for all the dependencies and sub-dependencies though for deterministic building of the final product. </div><div><br class=""></div><div>This only works because they all take full advantage of semantic versioning anyway.</div><div><br class=""></div><div><div class="">I particularly like Yehuda Katz's explanation on why it works this way: <a href="https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537" class="">https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537</a> </div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Rob...</div></div></div></div><div><br class=""></div></div><br class=""></body></html>