[swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

[Max Howell]

> Very happy this is coming! I really like the details of this proposal as well.
> 
> Just one thing - having the `VersionLocks` in `Packages/VersionLocks` seems like a bad idea to me. Couple of hurdles right away
> - for people who don't want to check in their dependencies, we can't just add `Packages` to our `.gitignore`, because that would make it impossible to check in the `VersionLocks` file (users would need to add exceptions to ignore Packages but keep the lockfile, which might result on users accidentally not committing their lockfile at all, which would defeat its whole purpose).

Yes, you have a point. I think it’s not a major issue, since `swift build —init` can be adapted to set up the gitignore properly, but we shouldn’t do it “just because”. I really dislike build systems cluttering the root directory of a project with more and more generated files. And for me the lockfile and the Packages directory are (more) on the same level of derivedness. And I think it makes it clearer that the lock applies only to your dependencies and not your own package.

`Packages` is generated, and the lockfile is generated into it. We hide .build for this reason.

> - `swift build --clean=dist` deletes the whole `Packages` directory, removing the lockfile, while I can imagine just wanting to delete and re-pull my dependencies with `swift build --clean=dist; swift build`. This will potentially generate a new lockfile, even though there was a completely valid one which I didn't explicitly say I want to overwrite. Again, we can add code to work around it, but needing to add so much exception code is a code smell to me.

Should a dist clean delete the lockfile? Probably IMO. If not, we can change the behavior.

> The two points above are just the low-hanging fruit that came into my mind. I prefer the approach CocoaPods takes with `Podfile.lock` being next to the repo manifest, instead of in the `Pods` folder (which instead contains a `Manifest.lock` AFAIK). So does Rubygems and others.

Indeed, it is not conventional. I’m not committed to the location in the proposal, but I do still prefer it.

> For me, a regular troubleshooting step is removing the `Packages` and `.build` folders and rebuilding. In my opinion, this step should **not** include the risk of altering the locked dependency graph, because both folders are just "Derived Data", however the VersionLocks file is a source of truth. 

True. Though we can make a clean step that leaves it, or adjust dist. But I agree that it is nice that you can just rm -rf. However there are trade offs either way, having it be easy to rm -rf isn’t exactly a design goal, it is just some nice behavior that fell out of having a nice initial design.

> And mixing source of truth with generated files feels very wrong to me.

> I'm happy to be proven wrong, but I'd suggest to move the location of the lockfile next to `Package.swift`. Having it in `Packages` causes a couple of issues right away without bringing any tangible benefits as far as I can see (not to mention diverging from other package managers like CocoaPods and Rubygems, which all keep the lockfile next to their manifest files - and seem to be happy with it for years).

If it is to be at the root, then probably it should have a `Package.something` name to make its association clear. Putting it in `Packages/` makes it possible to give it a better more descriptive name.