<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I'm replying here as a proxy for a bunch of other messages, since it is the latest one when I started typing. :)<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 14, 2016, at 12:40 PM, Ryan Lovelett <<a href="mailto:swift-dev@ryan.lovelett.me" class="">swift-dev@ryan.lovelett.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><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> <br class=""></div>
</div>
</div>
</div>
</blockquote><div class=""><br class=""></div>
<div class="">This was a powerful description for me. @Rob thank you for providing that!<br class=""></div>
<div class=""><br class=""></div>
<ol class=""><li class="">The articulation of the purpose/philosophy behind the whole thing was really clear and made sense to me. Even though I've never used Rust or Cargo. Nor have I ever run into any problems with npm such that I would prefer yarn over it. I've used Bundler for years and love it.<br class=""></li><li class="">Yehuda Katz has been involved in making 3 different package managers for 3 different communities/languages over at least a 6-year span. It feels trite but it seems likely he has knowledge/experience we might not. It might be wise to seriously consider the wisdom of others with experience.<br class=""></li></ol><div class=""><br class=""></div>
<div class="">I will say that like others on this thread prefer determinism in my builds.<br class=""></div>
<div class=""><br class=""></div>
<div class="">Whatever path leads me there is the path I want to walk. I'm not smart enough to say if this proposal will preclude that or not. I am moved by the notion that there are successful package managers out there as examples which today achieve that goal. <br class=""></div>
</div>
</div></blockquote></div><br class=""></div><div class="">Alexis, Huon and I just had an in person conversation about this thread, and I wanted to post a summary:</div><div class=""><br class=""></div><div class="">1. I think there is some confusion in the thread based on us not describing in the proposal exactly how the package manager *behaves today*, and the parts which we expected to be unchanged.</div><div class=""><br class=""></div><div class="">We effectively "pin locally" today, in the sense that we *never* update a dependency without the users involvement, and we all agree we should never ever ever ever do this. I don't personally understand how any tool would ever not do this, so I may have skipped over clarifying this. I'm not sure if there was confusion on this point, but if so, hopefully that helps.</div><div class=""><br class=""></div><div class="">We also give you a way to "see" what you are pinned at with `swift package show-dependencies`.</div><div class=""><br class=""></div><div class="">What this proposal about is in one sense being able to export and share those pins.</div><div class=""><br class=""></div><div class="">2. Huon, Alexis, and I all agree we should never *inherit* pins by default.</div><div class=""><br class=""></div><div class="">3. Huon pointed out using "shared" to mean "package intended to be used as a dependency" isn't correct, since one might often share a package intended to just be built and used as a command line tool. OTOH, I personally don't care for library vs executable since executables can often be used as dependencies for server-side stuff, or as build tools.</div><div class=""><br class=""></div><div class="">4. We also all agree that there are effectively two very different workflows based on whether a package is intended to be a dependency.</div><div class=""><br class=""></div><div class="">We have three very interesting ecosystems:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>A. Using packages as macOS/iOS/etc app dependencies.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>B. Using packages for server-side Swift code.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>C. Using packages to directly build command line tools and applications you can install.</div><div class=""><br class=""></div><div class="">In (A), all packages are dependencies, so our emphasis is on workflows oriented towards that.</div><div class=""><br class=""></div><div class="">In (B), we expect somewhat more sophistication around management of the pin file (w.r.t. PaaS deployment, continuous delivery, etc.), and so Huon and I at least agreed it was somewhat irrelevant. Also, we expect that more people developing in this space will simultaneously be factoring out packages which are intended to be dependencies.</div><div class=""><br class=""></div><div class="">In (C), by definition the most interesting and heavily used (as in installed) packages are *not* generally dependencies.</div><div class=""><br class=""></div><div class="">Today, (A) is a huge focus, and (B) is the main current consumer of SwiftPM. (C) is very interesting, and many of us would love to us it, but the reality is I don't see many people doing development in this space versus simply publishing via Homebrew, etc. Given that, my position is that *most* of the ecosystem is oriented towards packages which are intended to be dependencies, and we should choose our defaults accordingly.</div><div class=""><br class=""></div><div class="">5. Given that many people agree there are two workflows (we ourselves had talked about this a lot when writing the proposal, but didn't put it in), we felt it makes sense to consider adding that as an explicit declaration *somewhere*.</div><div class=""><br class=""></div><div class="">@Eloy, @Orta: Suppose we had a semantic notion of which packages were intended to be "top-level" versus used as a dependency, and we chose our defaults accordingly (in this case, we would orient workflows towards pinning by default in the top-level case, in the used as a dependency case we would orient away from it, e.g. warning you if you checked it in). What would you think of such a design?</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""></div></body></html>