<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 everyone,<div class=""><br class=""></div><div class="">I’d like to move this forward, I have the following points for discussion:</div><div class=""><br class=""></div><div class="">-----------</div><div class=""><br class=""></div><div class="">I would like to suspend this proposal’s submission pending update support which is due to be implemented after xcodeproj lands (which is done).</div><div class=""><br class=""></div><div class="">My rationale is: it impacts this proposal</div><div class=""><br class=""></div><div class="">-----------</div><div class=""><br class=""></div><div class="">I would like to suggest that the lockfile be placed as so:</div><div class=""><br class=""></div><div class=""> Packages/Lockfile</div><div class=""><br class=""></div><div class="">For me this fulfills the best of both worlds: it no longer seems to be a UNIX-style lockfile for the Package.swift file *and* it more clearly shows what precisely is being locked while continuing the perhaps unwise tradition of naming the file a “lockfile”</div><div class=""><br class=""></div><div class="">-----------</div><div class=""><br class=""></div><div class="">I would like to propose that initially the method that is used for altering branches, origins and pinning versions is not given an explicit CLI UI and instead the user must use explicit git commands in their Packages directory to set the “locks”.</div><div class=""><br class=""></div><div class="">The benefit here is that the process we are using is transparent, which allows developers more power over this feature and enables greater understanding over what happens.</div><div class=""><br class=""></div><div class="">Once the modifications are made the lock file can be regenerated by executing a command (TBD). Trying to run swift-build with modifications without first generating the lock results in a prominent warning, or perhaps even an error (TBD).</div><div class=""><br class=""></div><div class="">-----------</div><div class=""><br class=""></div><div class="">I would like the propose that any local changes to cloned packages that are NOT pinned to a commit are diff’d and the diff be embedded in the lockfile. This ensures that we:</div><div class=""><br class=""></div><div class="">1) Encourage users to edit, fix and improve their packages</div><div class="">2) Their changes get checked in and thus other people using the Package absolutely will get these changes without them having to explicitly publish their changes somewhere accessible to their whole team.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 14, 2015, at 10:43 AM, Ankit Agarwal <<a href="mailto:ankit@ankit.im" class="">ankit@ankit.im</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Hi,</div><div class=""><br class=""></div><div class="">Here is a proposal of the adding git branch support feature in SPM</div><div class=""><br class=""></div><div class=""><b class="">Introduction</b></div><div class=""><br class=""></div><div class="">Pointing to branch or a commit ref for dependencies in Package.swift as opposed to only a tagged release.</div><div class=""><br class=""></div><div class=""><b class="">Motivation</b></div><div class=""><br class=""></div><div class="">* Try a package which is almost stable or useable but not yet ready for a release/pre-release so not tagged (eg: new feature being introduced by a library)</div><div class="">* While developing packages, one would want to point a package that uses the package to a develop branch (eg: Developing Foo package, Bar uses Foo and wants to point Foo dep to develop branch)</div><div class="">* One would want to point to his own fork but not create a release while developing/testing (eg: Fork a library not compatible with SPM to make it compatible)</div><div class="">* One wants to point to some commit but doesn't have a branch/tag created for that</div><div class=""><br class=""></div><div class=""><b class="">Proposed solution</b></div><div class=""><br class=""></div><div class="">Allow refs and branch in Package.swift</div><div class=""><br class=""></div><div class="">let package = Package(</div><div class=""> name: "Hello",</div><div class=""> dependencies: [</div><div class=""> .Package(url: "ssh://<a href="http://git@example.com/Greeter.git" class="">git@example.com/Greeter.git</a>", branch: "develop", shouldFastForward: true),</div><div class=""> .Package(url: "ssh://<a href="http://git@example.com/FooBar.git" class="">git@example.com/FooBar.git</a>", commit: "d8ec7ca398a3ac3990477028117384d05ca7734e"),</div><div class=""> ]</div><div class="">)</div><div class=""><br class=""></div><div class=""><b class="">Detailed design</b></div><div class=""><br class=""></div><div class="">* Only the root Package.swift would be able to use branch/ref feature to avoid dependency hell, any other dependency fetched in current Package should not compile if that dependency contains another dependency pointing to a branch/ref</div><div class="">* This feature should strictly be used for testing/developing purpose and should not be deployed to production environments</div><div class=""><br class=""></div><div class="">SPM could have the following behavior when running `swift build` :</div><div class=""><br class=""></div><div class="">* If pointed to a branch, there might be two use cases </div><div class="">Since there is a high probability that user wants to point a branch due to active development of that dep and wants latest ref available in that branch</div><div class="">If a dependency is not cloned, clone it and checkout that branch</div><div class="">If shouldFastForward is on -> Always try to be on the latest ref, disregard any local changes made to the checked out package</div><div class="">If shouldFastForward is false -> Always try to be on the latest ref unless any local changes made to the checked out package</div><div class=""><br class=""></div><div class="">* If pointed to a ref : </div><div class="">If that dependency is not cloned, clone it and checkout that ref.</div><div class="">Consecutive `swift build` will not affect the cloned package</div><div class="">If changes are made in the cloned repo, rebuild that package with those changes</div><div class=""><br class=""></div><div class=""><b class="">Impact on existing code</b></div><div class=""><br class=""></div><div class="">None as this will be a new functionality</div><div class=""><br class=""></div><div class=""><b class="">Alternatives considered</b></div><div class=""><br class=""></div><div class="">One option is to only allow a commit ref and not a branch so SPM will not have to worry about fast forwarding but this is a desired feature.</div></div></div></blockquote></div><br class=""></div></body></html>