<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="">On Dec 19, 2015, at 8:41 AM, Ankit Agarwal &lt;<a href="mailto:ankit@ankit.im" class="">ankit@ankit.im</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Considering all the suggestions so far I am thinking of the following workflow :<div class=""><br class=""></div><div class="">.lock file will contain all the resolved dependencies in some simple format containing resolved version number or commit hash in case of untagged package. &nbsp;</div><div class=""><br class=""></div><div class="">1. Running initial `$ swift build` fetches all the dependencies specified in manifest file and generates a .lock file if not present and if present, updates .lock only for a new dependency introduced or for some dependency removed (or maybe not generate .lock at all?) but `$ swift build` always uses local state of Packages dir</div><div class=""><br class=""></div><div class="">2. To update the .lock file run something like `$ swift build --lock` which will always update the .lock file with local state of Packages dir.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">3. Commit and push the .lock file so others can reproduce the same environment using some command like `$ swift build --bootstrap` (like carthage)</div></div></div></blockquote><div><br class=""></div><div>Per <b class="">1.</b> `swift build` alone will do this. So unless `--bootstrap` has some other property, we probably don’t need it.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">4. If some dependency depends on branch/commit hash (ie non-tagged commit) the author mentions that in their readme and the end user and maybe other parallel dependencies will have to use only that tag in order to avoid dependency hell, this should probably be tackled with the #1 problem Daniel mentioned (<span style="font-size:13px" class="">alternate namespaces</span><span style="font-size:13px" class="">)</span></div></div></div></blockquote><div><br class=""></div>Yes, this seems like a good compromise to me. Projects that depend on non-standard branches have a solution they can use, but it is in their interest to speed up resolution of whatever situation is causing them to require the branch because it is slightly inconvenient to them and their users.</div><div><br class=""></div><div>I’m a big believer in making things possible, but creating social pressures that directs things for the overall good of the ecosystem.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">5. This proposal will address only .lock file problem and pointing to a different namespace will be taken care in a separate proposal.</div></div></div></blockquote><div><br class=""></div><div>As I understood Daniel’s 1), it is a tagging namespace for projects that cannot or do not want higher order tags like&nbsp;<font face="Courier New" class="">1.2.3</font>&nbsp;to be consumed as part of SwiftPM’s dependency resolution. I was thinking of tags like:</div><div><br class=""></div><div>&nbsp; &nbsp; swiftpm-1.2.3</div><div><br class=""></div><div>Would be treated as version&nbsp;<font face="Courier New" class="">1.2.3</font>, if there is also a&nbsp;<font face="Courier New" class="">1.2.3</font>&nbsp;tag, it will be ignored in preference to the&nbsp;<font face="Courier New" class="">swiftpm-1.2.3</font>&nbsp;tag if the&nbsp;<font face="Courier New" class="">swiftpm-1.2.3</font>&nbsp;tag is present.</div><div class=""><br class=""></div><div class="">This seems pretty simple, so maybe we can put it in with this proposal, otherwise&nbsp;</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">6. One issue that'll arrive with solving #2 outside manifest file is user wanting to use untagged dependency will have to enter some "fake" version in the manifest file.</div></div></div></blockquote><div><br class=""></div><div>Current discussion implies some `DevTarget` or similar concept in the manifest. This would override the need for git tags. However we need to flesh this out more as I have a number of concerns. After this perhaps! :)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Does this sound consistent with what you guys have in mind?</div></div></div></blockquote><br class=""></div><div>Yes, sounds just right. Thanks for writing this up. If you want to write up the proposal we can go from there. If you don’t have the time, I should have time early next week. Would be good to wait on Daniel for his opinion too, but he’s on break right now. It would be good to try and get this implemented sooner rather than later.</div><br class=""></body></html>