, hope everyone is staying safe!
I don't get much time to contribute to SwiftPM directly anymore, I still often get questions about SwiftPM enhancements or future directions.
While chatting about one such example on Twitter, one thing that occurred to me is that it might not be very clear to the community what are concrete examples of things kinds of enhancement proposals that are good candidates.
Also, while I barely contribute to SwiftPM anymore, we make very heavy use of SwiftPM in the work our team currently does, so I have a lot of opinions from managing large & complex graphs of SwiftPM projects.
With that in mind, here is my own personal "wishlist" of SwiftPM enhancements that are also unblocked from my perspective, in the sense that if someone wanted to show up with a proposal and an implementation, the project would be eager to work towards accepting them. This is just my personal list, as with an OSS project opinions may vary.
"Package Features": It would be very useful have something akin to Cargo's features mechanism in SwiftPM, so that packages could expose "knobs & switches" by which their clients could enable or control how the package was built. SwiftPM currently allows environment variables to be used for this purpose in the manifest, but it is a hack we really only allow because we don't have a proper feature for it. This is also somewhat related to more flexible build configurations or Bazel's configurable build attributes, although I see this as potentially orthogonal features.
"Distributable Artifacts": SwiftPM should really have some kind of feature akin to "xcodebuild install", not necessarily one that does the install, but one that does create a distributable artifact (tarball, lets say) of the built package. Right now, I often do this by just embedding a
Utilities/mkdistscript in the project that reaches into .build, creates the tarball, and also knows how to do various linking or RPATH tricks in order to make the artifact distributable, but really, SwiftPM should know how to do this for the platforms we support. This is particularly tricky to get right when you are trying to do things like build on one Linux distro an artifact that can be run on many different distros (including ones Swift doesn't actually yet formally support). (update, see: Swift Package Installation)
"Extensible Build Tools": SwiftPM should support the ability for one package to define new "build tools" (protobuf is a common example), and packages that want to use that tool can just depend on that package and then use new "build rules" to use those tools. Ankit has already talked about this here: Package Manager Extensible Build Tools
"Ad Hoc Actions": In my original thinking, I hoped that Extensible Build Tools could solve most of the need for "build system extensibility". However, as our team has worked more and more building complex SwiftPM packages, I have changed my thinking that SwiftPM should have both a "developer/API" extension level, as well as a more "ad hoc" / "quick & dirty" extension mechanism for very project-specific of rapidly evolving actions that shouldn't require building what is effectively a plugin (even if extensible build tools are very ergonomic). To that end, I now that SwiftPM should support some kind of highly-sandboxed and fine grained actions, most likely implemented using something very familiar to users of typical mechanisms in other languages, i.e. shell scripts. As our team has thought more deeply about how this should be managed at the llbuild level, we have realized there is a large opportunity to do so in a very "safe" way that doesn't preclude other SwiftPM/llbuild long term goals (like high degrees of cachability, distribution, or sandboxing).
"Shared Caches": Using SwiftPM on large graphs where a single developer often has many packages checked out leads to a ton of redundancy in the clones and built artifacts that SwiftPM has, making development annoying and slow. The goal for SwiftPM has always been to do something much more Nix like where SwiftPM's user experience stayed the same as it is today, but under the covers SwiftPM would intelligently cache artifacts based on strong hashes of the inputs, so that they could be reused.
"Modern Sandboxed/Cached Builds": Although more related to llbuild than SwiftPM, the longterm goal of llbuild has always been to move towards a more hermetic & cacheable build model (similar to that of Bazel) for all of the work, rather than rely on legacy style incremental builds which are highly filesystem / developer machine state dependent. This isn't necessarily something that would need a SwiftPM proposal, although the sandboxing would potentially have user facing impact and may need to be staged in. David (from the llbuild team) and myself have actually started exploring this in a very limited fashion, the llbuild repository now has a new cevobuild experiment in it where David is exploring what an "llbuild v2" API would be like, one that is much more actively focused at this type of build model (while preserving the other benefits of the llbuild model, like fully dynamic work discovery).
I'm less bullish on this one as a short term need, but I'd also be very interested to see more "tool" extensibility so that it is easier to plug in ad hoc CLI actions into SwiftPM. This is very useful for large projects (Vapor is probably a good example) that want to somehow piggy back on SwiftPM but then build additional domain specific commands that help with the kinds of operations users of that package want to do. This is conceptually similar to Ruby's
rakeand is also something I believe NPM has, although I'm not personally familiar with that ecosystem. This is also related to Bazel custom verbs.
I probably forgot at least one I constantly want.
If anyone has wanted to contribute more to SwiftPM, but isn't clear on where to start with crafting a proposal, I would be very happy to spend some time collaborating or consulting on designing a proposal on any of these topics.