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

I think TOML is no-go as its readme says: Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly. And I agree about YAML: no parser, more work, and more complicated. JSON sounds like a sane format. > On 04 Apr 2016, at

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

> This is a very welcome addition. Thanks! > > A nitpicky detail: I’d prefer the format for the lock file to be yaml or toml > over json, since those read a little easier in git diffs (which is, in my > experience with cocoapods lockfiles, the only place I ever interact with the > lockfiles

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

This is a very welcome addition. Thanks! A nitpicky detail: I’d prefer the format for the lock file to be yaml or toml over json, since those read a little easier in git diffs (which is, in my experience with cocoapods lockfiles, the only place I ever interact with the lockfiles contents). —

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

> On Mar 21, 2016, at 4:05 PM, Max Howell wrote: > >> 2. I like VersionLocks.json well enough, but would like to see a discussion >> about possible alternatives. My personal proposal (in line with #1) is to >> use "PackageVersions.json" which has a nice agreement with

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

> 2. I like VersionLocks.json well enough, but would like to see a discussion > about possible alternatives. My personal proposal (in line with #1) is to use > "PackageVersions.json" which has a nice agreement with Package.swift and > would mean two common metadata files show up adjacent. I

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

My thoughts on this proposal: 1. I agree with some of the other comments that I would prefer the version file be adjacent to "Package.swift". When the Packages directory isn't being checked in, I really would like to think of it as an "implementation detail" and not embed functionality inside

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

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`

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

> We decided to use a Swift-based format for the manifest because we believe it > gives developers the best experience for working with and describing their > project. The

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

> > > > >> We decided to use a Swift-based

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

> 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