<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="">Hi,<div class=""><br class=""></div><div class="">As noted by others, the standard extension for this file .lock, so I would prefer to keep that convention.</div><div class=""><br class=""></div><div class="">As I would never want my CI or any random team member to build a different package to what I've developed and tested already, I will always want Package.lock to exist. It's much easier if the system always creates Package.lock on swift package update and always uses it (if it exists) with swift build. This way, I get to choose when to go from 1.3.1 to 1.3.2 just in case I happen to depend on that bug that's now been fixed…</div><div class=""><br class=""></div><div class="">I can't see any downside to not creating it automatically and it results in so much more consistency across a team.</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Rob...</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Oct 2016, at 17:29, Daniel Dunbar 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="">Hey Orta,<div class=""><br class=""></div><div class="">Thanks for this feedback, this was one of the hotly debated points as you might imagine.</div><div class=""><br class=""></div><div class="">Can you elaborate on exactly how you would prefer this to work?</div><div class=""><br class=""></div><div class="">The way I see it, the only thing that this changes is that the initial package **author** who wants to be in this situation has to, one time, run "package pin --all", and then "git add Package.pins". The latter is always going to be necessary, so are you arguing the first should just be done by default, or is there something deeper here?</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 14, 2016, at 12:29 AM, orta therox 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="">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></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></body></html>