While I agree with that in principle, I think there’s a certain amount of tension between “SwiftPM the package manager” and “SwiftPM the build tool.” There are people who want the build tool to do things for their dev environment that a “package manager” shouldn’t do – and the lack of the ability of the package manager to define alternative local dependencies stifles many alternative workflows. So I’m offering an option that reduces the pain of moving to an alternative setup, one that also tries to reduce the churn for people who don’t need that flexibility.
But more than anything it takes that complexity off of a build-tool and makes it more opt-in for users.
In NodeJS, I can choose a test framework (qUnit, Jasmine, Mocha, among others), a bundler (Browserify, Webpack, Rollup, among others), and I can import and manage a pile of test-only and runtime dependencies, which means if I want a separate task-runner for my project, I just add gulp or grunt as a dev dependency.
In Java, I can install maven, gradle, or ant plugins. I can define different “profiles” in which those libraries are exposed. In Clojure, Leiningen plugins. In Ruby, I import code into a Rake task and call it.
Why can’t I do anything remotely close that with SwiftPM? I have to use XCTest (which has a horribly limited user experience on Linux) or SwiftPM won’t play. My test dependencies, if I even bother to try and put them into
Package.swift, are exposed to consumers of my package, which means that if two libraries depend on differing versions of a test dependency, anyone who consumes both is in trouble.
So while I agree with the idea that a build-tool shouldn’t be needlessly complex, I at least want to recognize that the problem-space itself is very complex, what with all the potential use-cases, and I think offloading that complexity to a generic process (resolve dependencies, run build file linking build-specific dependencies) is easier and offers less code-churn than any alternative I’ve yet seen, other than "let me specify local dependencies available in test environment,
or testTargets which aren’t XCTest bundles" which frustratingly also isn’t supported. this is kinda supported with targets that aren’t included in products, but even that exposes the dependencies of those targets to consumers
it’s not “Because YAML,” it’s “Because I Don’t See Swift As Solely The iOS App Language And Want It To Offer Similar Workflows And Use-Cases That Are Well-Worn In Languages It May Be Competing With It Like Node, Python, Ruby, and Others”
EDIT: Either of these approaches works. One jives with what was discussed in a Slack Q&A quite a while back and that may no longer be valid – been a busy few months and haven’t been able to weigh in, so if I’m out-of-date, please correct me!