TL;DR: I support the idea of “Swift Object Notation” DSL. I wish SPM made that goal more clear in the first place. I also really hope that SPM prioritizes providing tooling for programmatically editing the manifest. This is something every other dependency manager I know of has provided since day one. It’s not fair that package maintainers like me are pushed to finding hacks for programmatically editing the manifest just so our users can have a decent experience adding/removing our packages to their projects.
That is definitely a huge piece of knowledge I was missing. I had no idea that the
.swift file was supposed to be “Swift Object Notation” not just regular old Swift.
To be clear, I have only ever wanted a purely declarative package manifest. This entire proposal was centered around my desire to eschew the
Package.swift and the arbitrary Swift code execution that comes along with it.
The regex hacking can work for the time being. It is a really terrible solution, but the alternative is worse: It is really difficult (especially as a new programmer) to be required to understand SPM, GitHub, semver, etc just to add a simple package to your project.
I still can’t imagine how this will end up working. Even if you really pare down Swift into this JSON-like DSL, there are so many different ways you could write the manifest. For example:
// swift-tools-version:4.0 import PackageDescription let package = Package( name: "VaporApp", dependencies: [ .package(url: "https://github.com/vapor/vapor.git", from: "3.0.0-beta"), ], targets: [ ... ] )
// swift-tools-version:4.0 import PackageDescription let package = Package( name: "VaporApp", dependencies: [ ], targets: [ ... ] ) package.dependencies.append(.package(url: "https://github.com/vapor/vapor.git", from: "3.0.0-beta"))
I guess it would be fine for these subtle differences to converge into the “standard” way of defining the manifest upon serialization. But it seems like many underwater rocks will be encountered when the team actually sits down to implement this one.