[swift-build-dev] Proposal: Git Branch and ref support for dependencies in Swift Package Manager
Kostiantyn Koval
konstantin.koval1 at gmail.com
Mon Dec 14 15:36:55 CST 2015
+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> 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/20151214/d0855454/attachment.html>
More information about the swift-build-dev
mailing list