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