<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 19, 2015 at 11:27 PM, Max Howell <span dir="ltr"><<a href="mailto:max.howell@apple.com" target="_blank">max.howell@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div>On Dec 19, 2015, at 8:41 AM, Ankit Agarwal <<a href="mailto:ankit@ankit.im" target="_blank">ankit@ankit.im</a>> wrote:</div><br><div><div dir="ltr">Considering all the suggestions so far I am thinking of the following workflow :<div><br></div><div>.lock file will contain all the resolved dependencies in some simple format containing resolved version number or commit hash in case of untagged package. </div><div><br></div><div>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><br></div><div>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"><div><div dir="ltr"><div><br></div><div>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></div></span><div>Per <b>1.</b> `swift build` alone will do this. So unless `--bootstrap` has some other property, we probably don’t need it.</div></div></div></blockquote><div><br></div><div>I think we need the bootstrap property because `swift build` will read the local state of packages and builds the package where as bootstrap will be always reading from lock file and reproducing <b>exact</b> versions of the already present lock file. for eg : </div><div><br></div><div>Person A: </div><div>Runs `swift build`</div><div>fetches dependencies Foo at v1.2.<b>3</b> and Bar at v2.3.<b>4</b> and locks it.</div><div><br></div><div>Person B:</div><div>Runs `swift build`</div><div>fetches dependencies Foo at v1.2.<b>4</b> and Bar at v2.3.<b>6</b> (this can differ in patch versions which might not be the intention as both want to replicate exact versions, as running swift build will fetch the latest patch and minor version if only major is specified)</div><div>but if he runs `swift build --bootstrap` he'll get Foo at v1.2.<b>3</b> and Bar at v2.3.<b>4</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div>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">alternate namespaces</span><span style="font-size:13px">)</span></div></div></div></blockquote><div><br></div></span>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></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><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div>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></div></span><div>As I understood Daniel’s 1), it is a tagging namespace for projects that cannot or do not want higher order tags like <font face="Courier New">1.2.3</font> to be consumed as part of SwiftPM’s dependency resolution. I was thinking of tags like:</div><div><br></div><div> swiftpm-1.2.3</div><div><br></div><div>Would be treated as version <font face="Courier New">1.2.3</font>, if there is also a <font face="Courier New">1.2.3</font> tag, it will be ignored in preference to the <font face="Courier New">swiftpm-1.2.3</font> tag if the <font face="Courier New">swiftpm-1.2.3</font> tag is present.</div><div><br></div><div>This seems pretty simple, so maybe we can put it in with this proposal, otherwise </div><span class=""><div><br></div></span></div></div></blockquote><div><br></div><div>Agreed </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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></div></span><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><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div>Does this sound consistent with what you guys have in mind?</div></div></div></blockquote><br></span></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></div></blockquote></div><br>I was on break which ended now so I have plenty of time to do the proposal as well as try to do the implementation. Should I draft the proposal and raise a PR inside swift-package-manager/Documentation/Internals/ folder?<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ankit<br><br></div>
</div></div>