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

Mon Dec 14 13:14:34 CST 2015

+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> 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> 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", branch:
>> "develop", shouldFastForward: true),
>>         .Package(url: "ssh://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> wrote:
>>
>>> > On Dec 5, 2015, at 5:59 AM, Ankit Agarwal <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. 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);
>>> 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
> 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/20151214/edeec1d0/attachment.html>