<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><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><br></div><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><br></div><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><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><br></div><div>Does this sound consistent with what you guys have in mind?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 3:11 AM, Drew Crawford via swift-build-dev <span dir="ltr"><<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">+1 for lockfiles, although I would implement them slightly differently.<div><br></div><div>Again, this is a place where looking to Cargo's history is useful. Cargo.toml is roughly analagous to Packages.swift:</div><div><br></div><div><blockquote type="cite">[dependencies]<br>openssl-sys = { version = "0.5.0", git = "<a href="https://github.com/wycats/openssl-sys" target="_blank">https://github.com/wycats/openssl-sys</a>" }</blockquote></div><div><br></div><div>Then when you run `cargo update` it (in addition to building) generates a lock file:</div><div><br><blockquote type="cite">[[package]]<br>name = "openssl-sys"<br>version = "0.5.0"<br>source = "<a>registry+https://github.com/rust-lang/crates.io-index</a>"</blockquote></div><div><br></div><div>This lock file contains the exact software versions used to build. Subsequent invocation of `cargo build` use the version specified in the lockfile.</div><div><br></div><div>So to summarize:</div><div><br></div><div>1. `build` uses exact version specified in lockfile</div><div>2. `update` updates the lockfile to point to the newest versions compatible with the requirements in Packages.swift</div><div>3. lockfile always points to exact versions used</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Dec 15, 2015, at 2:30 PM, Max Howell via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a>> wrote:</div><br></div></div><div><div style="word-wrap:break-word"><div><div class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">2. Max had a great suggestion for how "locking" should work:</div><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> - "swift build --lock" (or however it is spelled) would simply create the .lock file based on the current state of your Packages tree.</div><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">This simple idea gives a great workflow for developing packages: you start by declaring your dependencies in your Package.swift, you use `swift build` to pull them down for you, then you start hacking on them (in your local checkout) to get the changes you need, iterating using `swift build --lock && swift build`, and then once you have something that works you can move to pushing those changes back and you already have the right .lock file</div></blockquote><br></div><div>To add more detail here, I propose that, initially you `swift build`:</div><div><br></div><div> $ swift build</div><div> $ cd Packages</div><div> $ ls</div><div> FooBar-1.2.3</div><div><br></div><div>Then you can step into Packages/FooBar-1.2.3 and change the branch:</div><div><br></div><div> $ git checkout mybranch</div><div><br></div><div>Then build against that branch</div><div><br></div><div> $ swift build</div><div><br></div><div>Now, to ensure consumers of your terminal-package or other members of your team are using the same packages as you, you need to commit the lock file:</div><div><br></div><div> $ git add ../../Packages.lock</div><div> $ git commit -m Lock against devbranch for FooBar</div><div> $ git push</div><div><br></div><div>Any .lock files that are cloned into dependencies are *ignored*. If a dependency depends on a branch of a package they should specify to the end-user that they will need to lock against that branch in their README.</div><div><br></div><div>The justification here is: dependency graphs are fragile, and introducing additional fragility should be avoided directly as part of our design going forward.</div><br><div>Now, we can add a convenience command line to do the above steps all in one, but exposing and documenting the mechanism transparently in the above manner offers consumers of swiftpm power and flexibility.</div><div><br></div><div>In addition the above workflow exposes a simple method for fixing issues in your dependencies directly without the need for convoluted tooling. Simply step into your Packages directory, make your changes and change the remote to your own fork, then lock.</div><div><br></div><div>Part of the proposal should thus make swiftpm emit warnings for modified packages without changes that are committed or pushed remotely. We don’t want people to accidentally push non-atomic changes to their dependency graph resulting in their teams not being able to build their projects.</div><div><br></div><div>Max</div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=OtwgWwWn2mvmck2XIGZZg64wEmoo4f4ILYe4SqMqwHrLhcfO3IuAhHoK8LzeaJKeQGh2UCzmKM0wv-2Fie03m0UrocvBWt2IEuC8AwalyPG6Kud6c1dhvtFSgooV6Lnm7OvKq2RiSGMLl6SCCB0TIF0f3LUC8UUiU2o2uMigZlbS9JmFmDf-2F9WuVmr4yTRUFj-2Blpg9USLZftNELIPvKNieK5k53F1oGlNmbFoKX25xvFs-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div><span class="">
_______________________________________________<br>swift-build-dev mailing list<br><a href="mailto:swift-build-dev@swift.org" target="_blank">swift-build-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br></span></div></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=AEA8HkHUydyAL-2BzBFOjUWuPXie04YFHRv-2BnVHbUI-2B6ceTqxq5rqLhpl7X8DY3E2Y3ZnBNS1LWIstjZWoRbLM1g11EbEVXJmpgfMY9OLZN1UnqNBB1qmbxJm0Ep3gdBFzl4AqmtK7dESssrEwDXy3RVEKXbBIPIx-2Fo56CkE4CRzTHWD2x-2Bhjbc7f2k10yMEZ9Xg5MvX6DRBgFqQGtu75cpg-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-build-dev mailing list<br>
<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ankit<br><br></div>
</div>