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

[Max Howell]

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

There will be a dedicated `—update` command that updates and it will update the lock per the current proposal. Expecting the build command to update the checked out dependencies every time seems unintuitive. It is after all a build command.

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

If we didn’t have lock files I still would not want `swift build` to update my dependencies before building, I would still want a separate --update switch, and in this case it would thus behave the same as if there is a lock file.

Updating your dependencies every build is asking for trouble, you wouldn’t want to be debugging and then also possibly have your underlying library dependencies change in behavior.

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

Maybe I don’t understand the problem here. Do you usually use tools that update dependencies before every build?

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

I think I don't understand your concern. The lockfile enables fresh checkouts can build deterministically with a known dependency graph. You don’t have to commit it, but you should. If you checkout and then want newer dependencies you build with --update.

Maybe if you provide your example from a time a lockfile hindered your workflow we can take it into account.