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

[Joshua Scott Emmons]

> I’d prefer a workflow that omits —bootstrap, to repeat my previous email:
> 
> If the lock file is committed I think swift-build should always use it. If the user wants newer updates they can execute `swift build —update`.
> 
> This makes understanding what happens simpler: `swift build` always uses the lock file if it is present.
> 
> This makes reliably building apps possible since you will always be building what everyone else built when the sources where committed.

Maybe it's me, but I've been burned by "Why isn't this updating — oh, there's a lock file!" more than once. Having "`swift build` always use a lock file if present" isn't simpler. It requires I reason about the state of the lock file every time I build.

If we want to be consistent, we should make `swift build` always build according to Package.swift — always. Then, if we want to build from locked versions, `swift build --use-locked-deps` would always build from the lock file (helpfully alerting us if it doesn't exist). This way we don't have to remember which does what when something exists or doesn't.

To look at it another way, I'm always aware when I want to build my packages to exactly match locked versions. I'm usually installing or deploying  and am focused on the task of building, itself. Asking me to to be explicit with `--use-locked-deps` at this step isn't a huge leap. 

I'm not always aware of when I *don't* want to build with locks, though. In that case I'm usually focused on development or testing or debugging. Building is just a side-effect. Asking me to be explicit with my intentions at this point (or, worse, asking me to reason about how build will behave based on the presence of other factors) feels like a nuisance. 

Just my 2¢,

-- 
-jemmons