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

[Max Howell]

> On Dec 19, 2015, at 8:41 AM, Ankit Agarwal <ankit at ankit.im> wrote:
> 
> Considering all the suggestions so far I am thinking of the following workflow :
> 
> .lock file will contain all the resolved dependencies in some simple format containing resolved version number or commit hash in case of untagged package.  
> 
> 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
> 
> 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.
> 
> 3. Commit and push the .lock file so others can reproduce the same environment using some command like `$ swift build --bootstrap` (like carthage)

Per 1. `swift build` alone will do this. So unless `--bootstrap` has some other property, we probably don’t need it.

> 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 (alternate namespaces)

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.

I’m a big believer in making things possible, but creating social pressures that directs things for the overall good of the ecosystem.

> 5. This proposal will address only .lock file problem and pointing to a different namespace will be taken care in a separate proposal.

As I understood Daniel’s 1), it is a tagging namespace for projects that cannot or do not want higher order tags like 1.2.3 to be consumed as part of SwiftPM’s dependency resolution. I was thinking of tags like:

    swiftpm-1.2.3

Would be treated as version 1.2.3, if there is also a 1.2.3 tag, it will be ignored in preference to the swiftpm-1.2.3 tag if the swiftpm-1.2.3 tag is present.

This seems pretty simple, so maybe we can put it in with this proposal, otherwise 

> 
> 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.

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! :)

> Does this sound consistent with what you guys have in mind?

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151219/7b4c2316/attachment.html>