By request, I'm taking this over from Twitter. Please pardon the semi-coherent info-dump.
The motivation is strong but I don't like this particular approach. My most frequent use-cases for creation (omitting, for example, libraries with samples):
- basic executable (about 10%)
- Swift Argument Parser executable (about 65%)
- libraries (about 15%)
The SAP executable is not addressed at all yet. So I have a lot of template folders and occasionally add building utilities to my command-line utils. I'm in the middle of breaking some of those out to their own SPM initializer util.
Every time I dive into to the SPM code, I throw up my hands in frustration as I'd prefer things to work better from that end. I'm not fond of how SPM currently handles hard-coded creation and agree strongly with the motivation.
A few more thoughts: Making Project.swift the primary end-user-facing point for project customization and control, especially outside the Xcode ecosystem, is confusing especially for new learners and those who create projects infrequently.
I particularly dislike the three "names" in the Project.swift file and the current set of comments. (The names roughly break down to project-name (often the same as a repo), module name, and the library or executable name that is produced and include one or more modules and/or dependencies.) These aren't explained in comments and the package init command uses the same name for each spot, which is particularly unhelpful.
Further, I know it is Applecentric to include comments about 5.1 being Mojave-friend, for example, but a link to recommended swift versions wouldn't be out of place and wouldn't have to be maintained from within the code (although it would outside).
Initialization does not include README.md, CHANGELOG.md, or LICENSE.txt. CHANGELOG in particular can be (but probably shouldn't be) generated with tags and a git history.
Initialization does not git init but generates a particularly unhelpful .gitignore, and does not check for a global gitignore. Any guiding json files (or yaml or whatever) should be able to be generated as a skeleton by SPM and then ignored with gitignore after. Hiding it down in five levels is unhelpful.
There's more but that's all I can think of at the moment.