I have posted our original proposal for using a Swift-based Manifest Format to the repo:
This proposal lays out in more concrete detail our exact intentions w.r.t.:
- The division between having a Turing complete build description language, but having it be strongly isolated from the build itself. Our intention is that the only interaction the manifest can have with the build process is through well-defined APIs. This is important for ensuring that we evolve the package manager effectively without breaking existing packages.
- The ability to have automatic editing support for the manifest file. Our intention is that the "leading package specification" (`let package = Package()`...) will be enforced to be written in such a way that we can provide APIs to automatically edit it. This is important for ensuring that we can provide eventual UI support, and for allowing us to build really great workflows where the package manager helps users write their files correctly.
- Explains our hope that by allowing programatic customization of the manifest (through Swift code), we can ultimately end up with a cleaner experience by not forcing us to design explicit APIs and solutions for all the ways people want to lay out their projects.
Please let me know if you have any feedback. I posted this one directly to the repo since we already went this direction and implemented it, in the future this is exactly the kind of proposal that we would like to handle via the swift-evolution process (and would then eventually make it into the repo once accepted and implemented).