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

[Ankit Agarwal]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151215/c8ca8af8/attachment.html>