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

[Ankit Agarwal]

On Sat, Dec 19, 2015 at 11:27 PM, Max Howell <max.howell at apple.com> wrote:

> On Dec 19, 2015, at 8:41 AM, Ankit Agarwal <ankit at ankit.im> wrote:
>
> Considering all the suggestions so far I am thinking of the following
> workflow :
>
> .lock file will contain all the resolved dependencies in some simple
> format containing resolved version number or commit hash in case of
> untagged package.
>
> 1. Running initial `$ swift build` fetches all the dependencies specified
> in manifest file and generates a .lock file if not present and if present,
> updates .lock only for a new dependency introduced or for some dependency
> removed (or maybe not generate .lock at all?) but `$ swift build` always
> uses local state of Packages dir
>
> 2. To update the .lock file run something like `$ swift build --lock`
> which will always update the .lock file with local state of Packages dir.
>
>
> 3. Commit and push the .lock file so others can reproduce the same
> environment using some command like `$ swift build --bootstrap` (like
> carthage)
>
>
> Per *1.* `swift build` alone will do this. So unless `--bootstrap` has
> some other property, we probably don’t need it.
>

I think we need the bootstrap property because `swift build` will read the
local state of packages and builds the package where as bootstrap will be
always reading from lock file and reproducing *exact* versions of the
already present lock file. for eg :

Person A:
Runs `swift build`
fetches dependencies Foo at v1.2.*3* and Bar at v2.3.*4* and locks it.

Person B:
Runs `swift build`
fetches dependencies Foo at v1.2.*4* and Bar at v2.3.*6* (this can differ
in patch versions which might not be the intention as both want to
replicate exact versions, as running swift build will fetch the latest
patch and minor version if only major is specified)
but if he runs `swift build --bootstrap` he'll get Foo at v1.2.*3* and Bar
at v2.3.*4*

4. If some dependency depends on branch/commit hash (ie non-tagged commit)
> the author mentions that in their readme and the end user and maybe other
> parallel dependencies will have to use only that tag in order to avoid
> dependency hell, this should probably be tackled with the #1 problem Daniel
> mentioned (alternate namespaces)
>
>
> Yes, this seems like a good compromise to me. Projects that depend on
> non-standard branches have a solution they can use, but it is in their
> interest to speed up resolution of whatever situation is causing them to
> require the branch because it is slightly inconvenient to them and their
> users.
>
> I’m a big believer in making things possible, but creating social
> pressures that directs things for the overall good of the ecosystem.
>
> 5. This proposal will address only .lock file problem and pointing to a
> different namespace will be taken care in a separate proposal.
>
>
> As I understood Daniel’s 1), it is a tagging namespace for projects that
> cannot or do not want higher order tags like 1.2.3 to be consumed as part
> of SwiftPM’s dependency resolution. I was thinking of tags like:
>
>     swiftpm-1.2.3
>
> Would be treated as version 1.2.3, if there is also a 1.2.3 tag, it will
> be ignored in preference to the swiftpm-1.2.3 tag if the swiftpm-1.2.3 tag
> is present.
>
> This seems pretty simple, so maybe we can put it in with this proposal,
> otherwise
>
>
Agreed

>
> 6. One issue that'll arrive with solving #2 outside manifest file is user
> wanting to use untagged dependency will have to enter some "fake" version
> in the manifest file.
>
>
> Current discussion implies some `DevTarget` or similar concept in the
> manifest. This would override the need for git tags. However we need to
> flesh this out more as I have a number of concerns. After this perhaps! :)
>
> Does this sound consistent with what you guys have in mind?
>
>
> Yes, sounds just right. Thanks for writing this up. If you want to write
> up the proposal we can go from there. If you don’t have the time, I should
> have time early next week. Would be good to wait on Daniel for his opinion
> too, but he’s on break right now. It would be good to try and get this
> implemented sooner rather than later.
>
>
I was on break which ended now so I have plenty of time to do the proposal
as well as try to do the implementation. Should I draft the proposal and
raise a PR inside swift-package-manager/Documentation/Internals/ folder?

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