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

2016-04-05 Thread David Hart via swift-evolution
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

2016-04-04 Thread Max Howell via swift-evolution
> 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

2016-04-04 Thread Lukas Stabe via swift-evolution
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

2016-04-03 Thread Daniel Dunbar via swift-evolution
> 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

2016-03-21 Thread Max Howell via swift-evolution
> 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

2016-03-19 Thread Daniel Dunbar via swift-evolution
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

2016-03-18 Thread Honza Dvorsky via swift-evolution
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

2016-03-18 Thread Ben Rimmington via swift-evolution
> 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

2016-03-18 Thread Max Howell via swift-evolution
> > > > >> We decided to use a Swift-based

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

2016-03-18 Thread Max Howell via swift-evolution
> 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