<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div></div><div style="direction: inherit;">Hey Daniel,</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Totally 👍</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">I think you should pin by default, I wouldn't even provide some option to disable it.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">As others have touched on, which I forgot to include, is that a library can choose to not include the lock file in SCM. Especially if the lib uses a CI for testing, that should bring up any issues with the latest versions of dependencies while keeping a paper trail (local lock file) of dependency versions that did work.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">The key here is that it remains an explicit choice. The default should imo always be consistent builds.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">----</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">With regards to being in a different position, I doubt it. Swift developers are, like in other languages, just humans, we all make mistakes. I think we've all accepted that we'll always introduce bugs any time we have to make decisions, the same applies to determining semantic versions.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">You could automate some of that (e.g. check interfaces), but you cannot guarantee behavioral intent and thus there's room left for human mistakes.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Please note, though, that I'm kinda pessimistic (realistic) about this and it's solely based on experience with established ecosystems, where people generally don't like being told how to do things. It may well be that your situation will turn out to be different.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">As the Queen would say, Godspeed!</div><div><br>On 14 Oct 2016, at 18:42, Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com">daniel_dunbar@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Hey Eloy,<div class=""><br class=""></div><div class="">Same question as I sent to Orta, can you detail exactly what you would prefer to change?</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 14, 2016, at 4:06 AM, Eloy Durán 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="">I cannot agree more with Orta.</div><div class=""><br class=""></div><div class="">> It drives the user away from taking full advantage of semantic versioning.<br class=""><br class="">While I ideally subscribe to this thought, the truth of the matter is that this has proven unreliable on multiple occasions. Promoting the idea that it works is going to inevitably lead users into problems when they did not take explicit user action to update dependencies.</div></div></div></blockquote><div><br class=""></div>This makes a lot of sense to me. The open question in my mind is, given our other goals, are we in a position to make this model work, or to make it "the right model for us". Some of the other things I am considering (and maybe should go into the proposal):</div><div><br class=""></div><div>1. Swift is still evolving in a much greater way than other languages. That means we continue to need to have a very strong push towards forward versions. This is also true for the package manager features, we need the ecosystem to move forward aggressively so that we can move our own features forward aggressively.</div><div><br class=""></div><div>2. We have some lofty goals around semantic versioning, like trying to have a much deeper integration with the compiler, API, and ABI, and testing in order to help manage this more effectively.</div><div><br 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="">Semantic versioning is a great tool when you decide to sit down and explicitly update dependencies.</div></div></div></blockquote><div><br class=""></div>The problem is they go hand in hand. The more people pin versus following the semantic versioning, the more and more likely it is that those specifications are wrong. That leads to more pinning, which leads to more wrong specifications.</div><div><br class=""></div><div>My preference is that we very aggressively commit to using semantic versioning, and then follow up with the entire cross functional design (an index, if we ever do one, the compiler features, any IDE integration) to make this work. I think we are in a better position than other tools which didn't have the ability to make as many cross functional changes (e.g., integration with the compiler to assist in semantic versioning).</div><div><br class=""></div><div>On the other hand, I am also very pragmatic, and I respect your experience here... if this model simply isn't going to work, then we shouldn't try to go that way.</div><div><br class=""></div><div>The big struggle I have is that if we go the other direction, and as a result people's semantic versions become poorly specified, we will never be able to recover. The converse is not true, if we start with this direction and realize it doesn't work, we can relax our behavior.</div><div><br class=""></div><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="">> 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.</div><div class=""><br class=""></div><div class="">Again, ideally I would subscribe to this, but the truth is that when people are working on their projects they *really really really* do *not* like their builds breaking, especially not when it’s seemingly caused outside of their own fault.</div></div></div></blockquote><div><br class=""></div>One discussion we had a lot was that there are very different workflows between when you are largely the consumer of packages, versus when you are working on a package that is shared.</div><div><br class=""></div><div>We generally agree that when you are simply the consumer of packages, pinning makes sense.</div><div><br class=""></div><div>However, when you are primarily a distributor of packages (and this is expected to *most* of the momentum behind SwiftPM in the near term), I believe that it is very important to the ecosystem that the semver specs be correct, and so even if the team *wants* to pin, doing so would be actively harmful.</div><div><br 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="">In the end, it comes down to whether you prioritise surfacing bugs (long term happiness) over user-experience (short term happiness). As a dependency manager author, I can tell you that I agree with your ideals and would want to choose the former, but as a user of dependency managers I would choose UX and Getting (The) Things (I Really Wanted To Do) Done over surfacing bugs *any* day.</div></div></div></blockquote><div><br class=""></div>I really appreciate the feedback. Do my arguments that we might be in a position to do better here have any weight with you?</div><div><br class=""></div><div> - Daniel</div><div><br 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=""><br class=""></div><div dir="ltr" class=""><span style="font-family: arial, sans-serif; font-size: 13px;" class="">[A.]<span style="white-space: pre-wrap;" class=""> </span>Eloy Durán<br class=""></span><span style="font-family: arial, sans-serif; font-size: 13px;" class=""><div style="margin: 0px;" class=""><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class=""> </span><a href="http://artsy.net/" target="_blank" class="">Artsy</a></div></span><span style="font-family: arial, sans-serif; font-size: 13px;" class=""><p style="margin: 0px;" class=""><span style="white-space: pre-wrap;" class=""> </span></p></span><span style="font-family: arial, sans-serif; font-size: 13px;" class=""><div style="margin: 0px;" class=""><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class=""> </span><a href="mailto:eloy@artsy.net" target="_blank" style="white-space: pre-wrap;" class="">eloy@artsy.net</a></div></span><span style="font-family: arial, sans-serif; font-size: 13px; white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap; font-family: arial, sans-serif; font-size: 13px;" class=""> </span><a href="https://twitter.com/alloy" target="_blank" class="">Twitter</a></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px;" class=""><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class=""> <a href="https://github.com/alloy" target="_blank" class="">GitHub</a></span></div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On 14 Oct 2016, at 09:29, orta therox via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@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="">Please don’t make this a separate command, it should ideally be created at the end of an build (when there isn’t one already) or an update of your dependencies - most people will be expecting to get the same set of dependencies as the rest of their team. This pattern makes that harder.<div class=""><br class=""></div><div class="">NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot of time trying to keep that up to date for our npm projects. Facebook made a replacement for NPM with mainly the feature of “always locking” in <a href="https://yarnpkg.com/" class="">yarn</a> and I’d expect that to take a lot of the JS mindshare on this one feature alone.<div class=""><div class="">
<div style="font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: 2; widows: 2; font-size: 13px; margin: 0px;" class=""><span style="text-align: -webkit-auto;" class=""><br class="Apple-interchange-newline">-- </span></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: 2; widows: 2; margin: 0px; color: rgb(35, 35, 35); min-height: 14px;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; color: rgb(35, 35, 35);" class=""><br class=""></div><div style="margin: 0px; color: rgb(35, 35, 35);" class="">[A.]<span class="Apple-tab-span" style="white-space: pre;"> </span> Orta Therox</div><div style="margin: 0px; color: rgb(35, 35, 35); min-height: 14px;" class=""><br class=""></div></div></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; color: rgb(35, 35, 35); min-height: 14px;" class=""><blockquote type="cite" style="background-color: rgb(255, 255, 255); border-left-color: rgb(0, 33, 98); color: rgb(0, 33, 98); border-width: 1px; margin-left: 0px; padding-left: 10px; padding-right: 0px; margin-right: 0px;" class=""><span style="border-collapse: collapse; color: rgb(34, 34, 34);" class=""><div style="margin: 0px;" class=""><span style="color: rgb(136, 136, 136);" class="">w/ </span><a href="http://artsy.net/" class="">Artsy</a></div></span></blockquote><blockquote type="cite" style="background-color: rgb(255, 255, 255); border-left-color: rgb(0, 33, 98); color: rgb(0, 33, 98); border-width: 1px; margin-left: 0px; padding-left: 10px; padding-right: 0px; margin-right: 0px;" class=""><span style="border-collapse: collapse; color: rgb(34, 34, 34);" class=""><div style="margin: 0px;" class=""><a href="http://cocoapods.org/" class="">CocoaPods</a> / <a href="http://cocoadocs.org/" class="">CocoaDocs</a><span style="text-align: -webkit-auto;" class=""> / </span><a href="https://itunes.apple.com/us/app/gifs/id961850017?l=en&mt=12" style="text-align: -webkit-auto;" class="">GIFs.app</a></div></span></blockquote></div></div></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; color: rgb(35, 35, 35); min-height: 14px;" class=""><blockquote type="cite" style="background-color: rgb(255, 255, 255); border-left-color: rgb(0, 33, 98); color: rgb(0, 33, 98); border-width: 1px; margin-left: 0px; padding-left: 10px; padding-right: 0px; margin-right: 0px;" class=""><span style="border-collapse: collapse; color: rgb(34, 34, 34);" class=""><div style="margin: 0px;" class=""><a href="http://twitter.com/orta" class="">@orta</a> / <a href="http://orta.github.com/" class="">orta.github.com</a></div></span></blockquote></div></div></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; color: rgb(35, 35, 35); min-height: 14px;" class=""><blockquote type="cite" style="background-color: rgb(255, 255, 255); border-left-color: rgb(0, 33, 98); color: rgb(0, 33, 98); border-width: 1px; margin-left: 0px; padding-left: 10px; padding-right: 0px; margin-right: 0px;" class=""><span style="border-collapse: collapse; color: rgb(34, 34, 34);" class="">Artsy is totally hiring <a href="https://artsy.net/job/mobile-engineer" style="text-align: -webkit-auto;" class="">iOS Devs</a> ATM</span></blockquote></div></div></div></blockquote></div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@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="">Hi,<div class=""><br class=""></div><div class="">We're proposing version pinning feature in Swift Package Manager. The proposal is available <a href="https://github.com/aciidb0mb3r/swift-evolution/blob/version-pinning/proposals/NNNN-Version-Pinning.md" class="">here</a> and also in this email:</div><div class=""><br class=""></div><div class="">Feedback welcomed!</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Ankit</div><div class=""><br class=""></div><div class="">--------</div><div class=""><br class=""></div><div class=""><h1 id="toc_0" style="-webkit-print-color-adjust: exact; margin-right: 0px; margin-bottom: 10px; margin-left: 0px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 28px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-top: 0px !important;" class="">Package Manager Version Pinning</h1><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class="">Proposal: SE-XXXX</li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class="">Author: <a href="https://github.com/ddunbar" style="-webkit-print-color-adjust: exact; color: rgb(65, 131, 196); margin-top: 0px;" class="">Daniel Dunbar</a>, <a href="https://github.com/aciidb0mb3r" style="-webkit-print-color-adjust: exact; color: rgb(65, 131, 196);" class="">Ankit Aggarwal</a></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class="">Review Manager: TBD</li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class="">Status: Discussion</li></ul><h2 id="toc_1" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 24px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Introduction</h2><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">This is a proposal for adding package manager features to "pin" or "lock" package dependencies to particular versions.</p><h2 id="toc_2" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 24px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Motivation</h2><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">As used in this proposal, version pinning refers to the practice of controlling <em style="-webkit-print-color-adjust: exact;" class="">exactly</em> which specific version of a dependency is selected by the dependency resolution algorithm, <em style="-webkit-print-color-adjust: exact;" class="">independent from</em> the semantic versioning specification. Thus, it is a way of instructing the package manager to select a particular version from among all of the versions of a package which could be chosen while honoring the dependency constraints.</p><h3 id="toc_3" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 18px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Terminology</h3><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""><em style="-webkit-print-color-adjust: exact;" class="">We have chosen to use "pinning" to refer to this feature, over "lockfiles", since the term "lock" is already overloaded between POSIX file locks and locks in concurrent programming.</em></p><h3 id="toc_4" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 18px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Philosophy</h3><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">Our philosophy with regard to pinning is that we actively want to encourage packages to develop against the latest semantically appropriate versions of their dependencies, in order to foster rapid development amongst the ecosystem and strong reliance on the semantic versioning concept. Our design for version pinning is thus intended to be a feature for package authors and users to use in crafting <em style="-webkit-print-color-adjust: exact;" class="">specific</em> workflows, not be a mechanism by which most of the packages in the ecosystem pin themselves to specific versions of each other.</p><h3 id="toc_5" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 18px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Use Cases</h3><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">Our proposal is designed to satisfy several different use cases for such a behavior:</p><ol style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Standardizing team workflows</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">When collaborating on a package, it can be valuable for team members (and continuous integration) to all know they are using the same exact version of dependencies, to avoid "works for me" situations.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">This can be particularly important for certain kinds of open source projects which are actively being cloned by new users, and which want to have some measure of control around exactly which available version of a dependency is selected.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Difficult to test packages or dependencies</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">Complex packages which have dependencies which may be hard to test, or hard to analyze when they break, may choose to maintain careful control over what versions of their upstream dependencies they recommend -- even if conceptually they regularly update those recommendations following the true semantic version specification of the dependency.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Dependency locking w.r.t. deployment</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">When stabilizing a release for deployment, or building a version of a package for deployment, it is important to be able to lock down the exact versions of dependencies in use, so that the resulting product can be exactly recreated later if necessary.</p></li></ol><h2 id="toc_6" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 24px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Proposed solution</h2><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">We will introduce support for an <strong style="-webkit-print-color-adjust: exact;" class="">optional</strong> new file <code style="-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;" class="">Package.pins</code> adjacent to the <code style="-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;" class="">Package.swift</code> manifest, called the "pins file". We will also introduce a number of new commands (see below) for maintaining the pins file.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">This file will record the active version pin information for the package, including data such as the package identifier, the pinned version, and explicit information on the pinned version (e.g., the commit hash/SHA for the resolved tag).</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">The exact file format is unspecified/implementation defined, however, in practice it will be a JSON data file.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">This file <em style="-webkit-print-color-adjust: exact;" class="">may</em> be checked into SCM by the user, so that its effects apply to all users of the package. However, it may also be maintained only locally (e.g., placed in the <code style="-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;" class="">.gitignore</code> file). We intend to leave it to package authors to decide which use case is best for their project.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">In the presence of a <code style="-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;" class="">Package.pins</code> file, the package manager will respect the pinned dependencies recorded in the file whenever it needs to do dependency resolution (e.g., on the initial checkout or when updating).</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">The pins file will not override Manifest specified version requirements and it will be an error (with proper diagnostics) if there is a conflict between the pins and the manifest specification.</p><h2 id="toc_7" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 24px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Detailed Design</h2><ol style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">We will add a new command <code style="-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;" class="">pin</code> to <code style="-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;" class="">swift package</code> tool with following semantics:</p><div style="-webkit-print-color-adjust: exact;" class=""><pre style="-webkit-print-color-adjust: exact; margin-top: 0px; margin-bottom: 15px; background-color: rgb(248, 248, 248); border: 1px solid rgb(204, 204, 204); font-size: 13px; line-height: 19px; overflow: auto; padding: 6px 10px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><code class="language-none" style="-webkit-print-color-adjust: exact; margin: 0px; padding: 0px; border: none; background-color: transparent; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">$ swift package pin ( [--all] | [<package-name>] [<version>] ) [--message <message>]</code></pre></div><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">The <code style="-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;" class="">package-name</code> refers to the name of the package as specified in its manifest.</p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">This command pins one or all dependencies. The command which pins a single version can optionally take a specific version to pin to, if unspecified (or with --all) the behaviour is to pin to the current package version in use. Examples: </p><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><code style="-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;" class="">$ swift package pin --all</code> - pins all the dependencies.</li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><code style="-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;" class="">$ swift package pin Foo</code> - pins <code style="-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;" class="">Foo</code> at current resolved version.</li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><code style="-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;" class="">$ swift package pin Foo 1.2.3</code> - pins <code style="-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;" class="">Foo</code> at 1.2.3. The specified version should be valid and resolvable.</li></ul><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">The <code style="-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;" class="">--reason</code> option is an optional argument to document the reason for pinning a dependency. This could be helpful for user to later remember why a dependency was pinned. Example: </p><div style="-webkit-print-color-adjust: exact;" class=""><pre style="-webkit-print-color-adjust: exact; margin-top: 0px; margin-bottom: 15px; background-color: rgb(248, 248, 248); border: 1px solid rgb(204, 204, 204); font-size: 13px; line-height: 19px; overflow: auto; padding: 6px 10px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><code class="language-none" style="-webkit-print-color-adjust: exact; margin: 0px; padding: 0px; border: none; background-color: transparent; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">$ swift package pin Foo --reason "The patch updates for Foo are really unstable and need screening."</code></pre></div></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Dependencies are never automatically pinned, pinning is only ever taken as a result of an explicit user action.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">We will add a new command <code style="-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;" class="">unpin</code>:</p><div style="-webkit-print-color-adjust: exact;" class=""><pre style="-webkit-print-color-adjust: exact; margin-top: 0px; margin-bottom: 15px; background-color: rgb(248, 248, 248); border: 1px solid rgb(204, 204, 204); font-size: 13px; line-height: 19px; overflow: auto; padding: 6px 10px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><code class="language-none" style="-webkit-print-color-adjust: exact; margin: 0px; padding: 0px; border: none; background-color: transparent; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">$ swift package unpin ( [--all] | [<package-name>] )</code></pre></div><p style="-webkit-print-color-adjust: exact; margin: 15px 0px;" class="">This is the counterpart to the pin command, and unpins one or all packages.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">We will fetch and resolve the dependencies when running the pin commands, in case we don't have the complete dependency graph yet.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">We will extend the workflow for update to honour version pinning, that is, it will only update packages which are unpinned, and it will only update to versions which can satisfy the existing pins. The update command will, however, also take an optional argument <code style="-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;" class="">--repin</code>:</p><div style="-webkit-print-color-adjust: exact;" class=""><pre style="-webkit-print-color-adjust: exact; margin-top: 0px; margin-bottom: 15px; background-color: rgb(248, 248, 248); border: 1px solid rgb(204, 204, 204); font-size: 13px; line-height: 19px; overflow: auto; padding: 6px 10px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><code class="language-none" style="-webkit-print-color-adjust: exact; margin: 0px; padding: 0px; border: none; background-color: transparent; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">$ swift package update [--repin]</code></pre></div><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Update command errors if there are no unpinned packages which can be updated.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Otherwise, the behaviour is to update all unpinned packages to the latest possible versions which can be resolved while respecting the existing pins.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">The <code style="-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;" class="">[--repin]</code> argument can be used to lift the version pinning restrictions. In this case, the behaviour is that all packages are updated, and packages which were previously pinned are then repinned to the latest resolved versions.</p></li></ul></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">The update and checkout will both emit logs, notifying the user that pinning is in effect.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">The <code style="-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;" class="">swift package show-dependencies</code> subcommand will be updated to indicate if a dependency is pinned.</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">As a future extension, we anticipate using the SHA information recorded in a pins file as a security feature, to prevent man-in-the-middle attacks on parts of the package graph.</p></li></ol><h2 id="toc_8" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 24px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Impact on existing code</h2><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">There will be change in the behaviours of <code style="-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;" class="">swift build</code> and <code style="-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;" class="">swift package update</code> in presence of the pins file, as noted in the proposal however the existing package will continue to build without any modifications.</p><h2 id="toc_9" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 24px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(204, 204, 204); font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Alternative considered</h2><p style="-webkit-print-color-adjust: exact; margin-top: 15px; margin-right: 0px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255); margin-bottom: 0px !important;" class="">We considered making the pinning behavior default on running <code style="-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;" class="">swift build</code>, 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.</p></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-build-dev mailing list<br class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-build-dev mailing list<br class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</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">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></body></html>