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

Tue Dec 15 02:03:04 CST 2015

There is a plan to add ability to support fetching packages by url for development purpose described here
Importing Dependencies by Source URL form "PackageManagerCommunityProposal" 
https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#importing-dependencies-by-source-url

Kostiantyn

> On 14 Dec 2015, at 22:36, Kostiantyn Koval <konstantin.koval1 at gmail.com> wrote:
> 
> +1 for adding this.
> 
> Ability to point to commit instead of a tag is crucial. 
> Often happens that a bug was fixed in the depended library but it wasn't released/tagged.
> As well it helps during development.
> 
> Kostiantyn
> 
>> On 14 Dec 2015, at 20:14, Marc Knaup via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>> 
>> +1 since I had to do exactly that a couple of times with CocoaPods.
>> There were issue in third party Pods which were fixed in a specific commit or branch but the official release would still take a while. Delaying our app release because of that was not an option and referring to a fixed yet unreleased version the best solution. 
>> 
>> On Dec 14, 2015 8:04 PM, "Ankit Agarwal via swift-build-dev" <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>> Correcting one of the sentences in the Detailed design section
>> 
>> * If pointed to a branch, there might be two broad use cases
>> 1. User wants to point a branch due to active development of that dep and wants latest ref available in that branch
>> 2. User is actively developing a dep in that branch and want to test it out in the current package
>> 
>> 
>> On Tue, Dec 15, 2015 at 12:13 AM, Ankit Agarwal <ankit at ankit.im <mailto:ankit at ankit.im>> wrote:
>> 
>> Hi,
>> 
>> Here is a proposal of the adding git branch support feature in SPM
>> 
>> Introduction
>> 
>> Pointing to branch or a commit ref for dependencies in Package.swift as opposed to only a tagged release.
>> 
>> Motivation
>> 
>> * 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)
>> * 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)
>> * 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)
>> * One wants to point to some commit but doesn't have a branch/tag created for that
>> 
>> Proposed solution
>> 
>> Allow refs and branch in Package.swift
>> 
>> let package = Package(
>>     name: "Hello",
>>     dependencies: [
>>         .Package(url: "ssh://git@example.com/Greeter.git <http://git@example.com/Greeter.git>", branch: "develop", shouldFastForward: true),
>>         .Package(url: "ssh://git@example.com/FooBar.git <http://git@example.com/FooBar.git>", commit: "d8ec7ca398a3ac3990477028117384d05ca7734e"),
>>     ]
>> )
>> 
>> Detailed design
>> 
>> * 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
>> * This feature should strictly be used for testing/developing purpose and should not be deployed to production environments
>> 
>> SPM could have the following behavior when running `swift build` :
>> 
>> * If pointed to a branch, there might be two use cases 
>> 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
>> If a dependency is not cloned, clone it and checkout that branch
>> If shouldFastForward is on -> Always try to be on the latest ref, disregard any local changes made to the checked out package
>> If shouldFastForward is false -> Always try to be on the latest ref unless any local changes made to the checked out package
>> 
>> * If pointed to a ref : 
>> If that dependency is not cloned, clone it and checkout that ref.
>> Consecutive `swift build` will not affect the cloned package
>> If changes are made in the cloned repo, rebuild that package with those changes
>> 
>> Impact on existing code
>> 
>> None as this will be a new functionality
>> 
>> Alternatives considered
>> 
>> 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.
>> 
>> On Tue, Dec 8, 2015 at 4:24 AM, Rick Ballard <rballard at apple.com <mailto:rballard at apple.com>> wrote:
>> > On Dec 5, 2015, at 5:59 AM, Ankit Agarwal <ankit at ankit.im <mailto:ankit at ankit.im>> wrote:
>> >
>> > Hi,
>> >
>> > Is pointing to a branch instead of version for a package in scope of SPM?
>> > if it is, I'd love to try to implement it
>> 
>> Hi Ankit,
>> 
>> This is in scope, though not yet designed. Prior to anyone working on an implementation, we should agree on a design for how you'd do this. While this isn't at the top of our priority list at the moment, we'd welcome both design contributions and eventual implementation.
>> 
>> If you'd like to put a proposal together for this, please see the Swift evolution process at https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>. We'd be happy to discuss this here as part of your process for putting a proposal together. Some things to think about in this area are:
>> 
>> – How should refs (branches or tags) that aren't simple version numbers be specified?
>> 
>> – Right now we require you to tag something as a versioned "release". Should we require that you tag a branch before someone can make a package depend on it? It could be convenient to be able to just depend on a branch, but the meaning of depending on a branch changes over time as more commits come in. Is it harmful to allow packages to depend on something that's not an identified commit?
>> 
>>         – Note that we have yet to design our security story (https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#security-and-signing <https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageManagerCommunityProposal.md#security-and-signing>); what we settle on there might require dependencies to be specified as a specific tagged commit, so that it can be signed.
>> 
>> – Should it be possible to override a package's dependency to use a different branch, without having to modify and commit a change to that package's Package.swift?
>> 
>> – We may want to design a way for packages to support different versions of the Swift language, as the language continues to change – e.g. a branch of the package for the last released swift vs the current under development swift snapshot. Is supporting dependencies on package branches a part of how we'll do that?
>> 
>> Thanks,
>> 
>>         - Rick
>> 
>> 
>> 
>> 
>> -- 
>> Ankit
>> 
>> 
>> 
>> 
>> -- 
>> Ankit
>> 
>>  
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
>> 
>>  _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>

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