> 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.
Completely agree — except that according to the proposal, the lockfile is generated *every* time `swift build` is run (assuming a lockfile doesn't already exist). So we can't really treat its presence as indicating some sort of intention. It's going to be there all the time for everyone whether they understand it, want to use it, or not. Unless I'm missing something? Actually, if we changed this part of the proposal such that the lockfile would *only* be generated explicitly (in response to `swift build --lock`, for example?), I'd be in agreement with you that vanilla `swift build` should always use the lockfile by default. For, in this case, there would be only two ways a lockfile could exist: 1) you explicitly create it 2) the team/maintainers of the code think it's important In either case, building with the lockfile is clearly the Right Thing to do. This feels like a much more fruitful compromise than per-project, per-user overrides… assuming anyone else is on board with forcing lockfile creation to be explicit. Thoughts? -- -jemmons _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
