<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=""><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=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div style="direction: inherit;" class="">Totally đź‘Ť</div></div></div></div></blockquote><div class=""><br class=""></div>I'm not sure what this is to. :)</div></div></div></blockquote><div><br class=""></div><div>You and me both… Guess I must have lost track of my thought here while trying to respond from my phone and playing with the baby in between.</div><div><br class=""></div><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="">Pin by default in the sense you are using it just means we automatically would create "Package.pins", that is the only behavior change (i.e., you don't inherit it from your dependencies).</div></div><div class=""><br class=""></div><div class="">Can you explain why simply needing to run one more command when you want to do this is a big deal?</div></div></blockquote><div><br class=""></div>It’s clearly not a big deal in amount of work, what it comes down to is setting an example. If you, as an authority, make it the default option to not pin, then to many people that will signal that that’s The Right Thing to do.</div><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="">Is it possible that we have a different expectation about what the tools do when you don't create this file?</div></div></blockquote><div><br class=""></div>No, it’s a philosophical difference in thinking about dependencies.</div><div><br class=""></div><div>I see it as my responsibility to know exactly what code I’m pulling into my package. In my view, it’s absolutely unsafe to trust other people’s code. Even when they mean no harm, trusting them to properly apply SemVer is the same issue.</div><div><br class=""></div><div>My worst nightmare is people updating dependencies and getting lazy in vetting them, a mindset that is in my observation the status quo in e.g. npm, a dependency manager which makes it the default to not pin and trust SemVer. On the other hand, the laziness might also be compounded by the micro-lib norm, it’s not unusual for npm packages to have a dependency graph of dozens, if not hundreds of packages.</div><div><br class=""></div><div>This also leads me to the following point you bring up:</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">One argument I haven't heard anyone refute is that we can always back down from this position, but the converse isn't true (because its impact will have permeated the ecosystem). I consider that an important point.</div></div></blockquote><br class=""></div><div>The reason I would not try to refute it is A) simply because it’s true and B) it’s, to me, more of a technicality that’s moot in contrast to my philosophical thoughts, as explained above.</div><div><br class=""></div><div>One final note, playing the devil’s advocate against my own opinion, seeing as you are at a place where you can try it and later change, I’d say do it. However, it might be a good idea to document the possibility of this changing in the future, just so expectations are set correct and the thought to keep an eye on this is kept alive in the community.</div></body></html>