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

[Ankit Agarwal]

Looks good.

What about getting packages that don't have any semver tags initially?
For eg I create a package and want to use it in a different package while
also developing the original package and I did a `git init` but not `git
tag v0.0.1`?

On Fri, Mar 4, 2016 at 1:37 AM, Max Howell <max.howell at apple.com> wrote:

> Hi everyone,
>
> I’d like to move this forward, I have the following points for discussion:
>
> -----------
>
> I would like to suspend this proposal’s submission pending update support
> which is due to be implemented after xcodeproj lands (which is done).
>
> My rationale is: it impacts this proposal
>
> -----------
>
> I would like to suggest that the lockfile be placed as so:
>
>     Packages/Lockfile
>
> For me this fulfills the best of both worlds: it no longer seems to be a
> UNIX-style lockfile for the Package.swift file *and* it more clearly shows
> what precisely is being locked while continuing the perhaps unwise
> tradition of naming the file a “lockfile”
>
> -----------
>
> I would like to propose that initially the method that is used for
> altering branches, origins and pinning versions is not given an explicit
> CLI UI and instead the user must use explicit git commands in their
> Packages directory to set the “locks”.
>
> The benefit here is that the process we are using is transparent, which
> allows developers more power over this feature and enables greater
> understanding over what happens.
>
> Once the modifications are made the lock file can be regenerated by
> executing a command (TBD). Trying to run swift-build with modifications
> without first generating the lock results in a prominent warning, or
> perhaps even an error (TBD).
>
> -----------
>
> I would like the propose that any local changes to cloned packages that
> are NOT pinned to a commit are diff’d and the diff be embedded in the
> lockfile. This ensures that we:
>
> 1) Encourage users to edit, fix and improve their packages
> 2) Their changes get checked in and thus other people using the Package
> absolutely will get these changes without them having to explicitly publish
> their changes somewhere accessible to their whole team.
>
>
> On Dec 14, 2015, at 10:43 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.
>
>
>


-- 
Ankit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160304/0837a0df/attachment.html>