[swift-build-dev] Proposal: Git Branch and ref support for dependencies in Swift Package Manager

[Max Howell]

> 2. Max had a great suggestion for how "locking" should work:
>  - "swift build --lock" (or however it is spelled) would simply create the .lock file based on the current state of your Packages tree.
> 
> 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

To add more detail here, I propose that, initially you `swift build`:

    $ swift build
    $ cd Packages
    $ ls
    FooBar-1.2.3

Then you can step into Packages/FooBar-1.2.3 and change the branch:

    $ git checkout mybranch

Then build against that branch

    $ swift build

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:

    $ git add ../../Packages.lock
    $ git commit -m Lock against devbranch for FooBar
    $ git push

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.

The justification here is: dependency graphs are fragile, and introducing additional fragility should be avoided directly as part of our design going forward.

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.

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.

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.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151215/f889fd1b/attachment.html>