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

[Max Howell]

>> 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?

I think it is reasonable to always create it, you don’t *have* to commit it and check-it-in.

By always creating it we are suggesting the file is important, and that you *should* check it in. Which is right, it is important, and you *should* check it in. However you don’t *have* to, and when it comes to development, it is important to offer choices.