[swift-build-dev] [swift-evolution] [Proposal] Lock file for Swift Package Manager

[Pierre Monod-Broca]

> Le 23 déc. 2015 à 18:17, Max Howell via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> Right. I didn't mean to insinuate we should be pulling fresh dependencies before each build. Here's the scenario 
>> 
>> * I'm working on a package that depends on FooPackage Version(1,0,0)..<Version(2,0,0)
>> * I `swift --update`. This pulls FooPackage v1.1 and sets the lockfile. I commit the lockfile to git.
>> * FooPackage v1.2 is released
>> * A co-worker `swift --update`s to FooPackage v1.2, her lockfile is updated and she pushes it to git.
>> * Version 1.3 is released.
>> * I pull my co-worker's commits.
>> 
>> Here's the state of things at this point:
>> * The FooPackage currently checked out in my Packages directory is v1.1
>> * My lockfile points at FooPackage v1.2
>> * The latest FooPackage I could be using is v1.3
>> 
>> There are three things that should be possible at this point:
>> 1. Build with the existing v1.1 dep.
>> 2. Update deps to the lockfile version (v1.2).
>> 3. Update deps and lockfile to the latest conforming version (1.3).
>> 
>> I'm simply saying that I'd expect vanilla `swift build` to perform option #1 (perhaps with a warning message that we're out of sync with the lockfile). Like you say, "expecting the build command to update the checked out dependencies every time seems unintuitive. It is after all a build command." So I'd expect it to build with what's already there. If I wanted to update deps to the lockfile version, I could be explicit: `swift build --use-locked-deps`. 
> 

Personally, I often work offline, and currently I'm often working on a project and its dependencies at the same time.
For those two reasons, *in the current proposal state* #1 would be my preferred choice (with proper warnings).

I would totally support for #2 to be the default, if it doesn't touch dependencies with local modifications, committed or uncommitted, but rather simply warn about them. Detection of committed changes could be achieved with spm keeping a copy of the lock it used last, for exemple.

Also that makes me think there could be a warning if #3 hasn't been used in a while.

-- 
Pierre

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