SwiftPM today supports specifying system packages as being provided by a package manager (apt, winget, yum and brew). While we can record this information in our Package.swift, it's not used in any tool available today.
While I'm content with SwiftPM not using this information directly, I still think it's valuable to consume this information as part of external tools.
For example;
swift-container-plugin could add support for installing these dependencies (and potentially OS) in base layers.
swift-sdk-generator could generate a sysroot based on your your dependencies. Allowing you to build an SDK for the Container Plugin's final environment.
I can also imagine other tools being created, like a hypothetical swift package install-dependencies which installs the dependencies on your current OS.
While swift package dump-package currently exposes this data for the current package, there is to my knowledge no existing SwiftPM verb to expose this for a single executable including its dependency hierarchy.
This means I can currently print this data for an SDL library, but not the executable consumer of this library. Is this an API that could be exposed in some form?
So for an “external tool” for generating Swift SDKs do you envision this being perhaps a SwiftPM plugin or just a separate app you run on a Package.swift that’ll generate the Swift SDK for you? Maybe there could even be a JSON file in the project to configure what kind of Swift SDK to generate (OS, version, target triple, and so on) and that invokes the swift-sdk-generator.
Also I need to note, right now the swift-sdk-generator does not have support for adding additional dependencies when generating a Swift SDK. The only way to do this right now is to create a container first with the dependencies, then generate the Swift SDK off of that. But, perhaps building this into the generator itself could be something we could consider.
I think that defining what OS to run on is a swift-sdk-generator concern, not a Package.swift one. Package.swift is platform agnostic (except for the knoweldge of package managers), and I think tha'ts fine.
But yes, I think tools should care about these non-Swift dependencies. Another use case is generating SBOMs. It's nice to have a bill of materials for the Swift side, but the binary artifacts and dynamic libraries etc are also very relevant! Right now, that data is lost.
Adding this information to the command plugin package graph API + textual output of some combination of describe / dump-package sounds good to me. It’s generally useful information to expose for higher level tools to consume, and (IMO) exposing it doesn’t meaningfully constrain future evolution of package plugins/manifests/etc.
A lot of what I am planning for SwiftPM involves adding new plug-in types to extend SwiftPM in strategic ways. I think it’s fair to consider that possibility to the mix here as well.
Given the right plug-ins I would like to see SwiftPM being able to install these dependencies on the host system. I haven’t thought about building container images too much yet, but I’d like SwiftPM to be able to construct those again with the right plug-ins, and if it knows all the needed system dependencies for a target, it could install those too into the image.
I am also considering SwiftPM being able to generate SDKs itself. But I’ll save that for the forum post I’m preparing :).
At this point, let’s think big. What would the ideal workflow look like if you expanded packages to support those workflows in an automated fashion. i.e. swift run just works!