>> 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
