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

[Max Howell]

> 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`. 

Right, I understand now.

> My understanding, though, is that if a lockfile is present, `swift build` would operate like option #2 and I'd need to be explicit about my desire to ignore the lockfile (maybe with `swift build --ignore-locked-deps` or the like). This feels inconsistent in that sometimes `swift build` just builds what's there, and sometimes updates and builds depending on the state of the lockfile. It also feels a little wrong that vanilla `build` could checkout other branches without me passing `--something`.

I agree, that the functionality is less simple and in fact it is ingenious of me to claim it just “builds”.

I think #2 is the correct choice because if the lockfile is present then the team that works here is stating that they *want* their team to use those dependencies. And they want everyone on their team to be using the exact same sources so any bugs reported do not have to take into account any variation in dependency sources.

However I would be happy to see a proposal for a per-project, per-user configuration to override this, or perhaps just a command line flag.

The tool should cater to all needs (if possible and practical), but with sensible defaults.

> But it certainly sounds like I'm in the minority here, so no big deal.

Perhaps, but we’re all a minority in some workflow: development is a personal process. You should submit a proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151223/ab79fe8c/attachment.html>