<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 Dec 5, 2016, at 8:09 PM, 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 2, 2016, at 11:11 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 28, 2016, at 8:25 PM, 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=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div>I agree with this feeling, but am not sure how much it will matter in practice.</div></div></div></blockquote><div class=""><br class=""></div><div class="">As I said in my review, I suspect it will confuse newcomers and lead to a few much-duplicated questions on Stack Overflow, but not hurt teams whose workflow is already established. One-time cost, not so bad.</div><br class=""><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="">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.</div></div></div></blockquote><div class=""><br class=""></div>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.</div></div></blockquote><div class=""><br class=""></div><div class="">Understood.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">If you have a concrete proposal on a better way to implement this I would love to hear it.</div></div></blockquote><div class=""><br class=""></div><div class="">I chewed this over, and sketched out a variant that I thought was simpler. I then realized that what I came up with is basically identical to the existing proposal, except:</div><div class=""><br class=""></div><div class="">1. I renamed `--enable-autopin` to `pin --new`.</div><div class="">2. It doesn’t have the convenience of new requiring `--repin` if everything is already pinned.</div><div class=""><br class=""></div><div class="">At least I _think_ what I came up with is nearly identical. Here it is in case you want to check me on that:</div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/pcantrell/10cf1cc2cc2d8f1b5011e0ea5f828402" class="">https://gist.github.com/pcantrell/10cf1cc2cc2d8f1b5011e0ea5f828402</a></div></div></div></div></blockquote><div><br class=""></div><div>Yeah, I think this is basically equivalent (the "private pin file" is effectively our current local storage of what versions are cloned).</div><div><br class=""></div><div>The idea of having `--all` automatically drive the boolean did occur to me, but seemed too magic (and we would still want a way to turn it off).</div></div><div><br class=""></div><div>Thanks for trying, though!</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=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Agreed! This is a fine starting point.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div></div><br class=""></div></div></blockquote></div><br class=""></body></html>