> Le 23 déc. 2015 à 18:17, Max Howell via swift-evolution > <swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
