[PITCH] Support for binary dependencies

Development Package Manager
51

Thanks for the summary @ddunbar. The title of this pitch does seem to imply a general solution for binary support, even thought there might be missing pieces to achieve that goal. It sounds like there are different discussions that need to happen to fully resolve this particular design. Taking from the list of things you mentioned:

  1. API for Package.swift: This seems to be the topic that is unblocked from being defined implemented and where discussions should focus right now, based on the other considerations listed below.
    Open questions here:

    1. How to deal with security so that clients can be sure that the artifact they trusted continues to be trusted as the dependency evolve. Another part of this question is the transitive trust for indirect dependencies.
    2. Should the binary targets be defined in the client or in the provider? What I mean by this is whether CompanyA exposes a Package.swift with .binaryTarget pointing to the artifact, or a client developer adding a binary dependency similar to .package, removing the need for CompanyA to provide a Package.swift file at all, at the cost of SPM understanding how to interpret that binary dependency, this is tied to Format for the artifact/artifact manifest

  2. Format for the artifact/artifact manifest: I think this is what Binary Target Artifact Format aims to describe in the pitch, though it might need more elaboration.
    Open questions here are:

    1. @lukasa's question on how to handle Linux ABI across different distributions/platforms. I have no insight here.
    2. Should we choose a format that allows downloading only what's required for the target platform, as opposed to the full artifact with all the binaries, potentially an expensive action if the artifact supports many platforms. Given the push for XCFrameworks as the standard for Apple platforms, this might mean a central service that understands the structure of the XCFrameworks, or a full download of XCFrameworks. My preference here is to download the full artifact for now, as that simplifies current work but still leaves this part open for future discussion and solution

  3. Support for runtime dependencies: This is what I was initially asking about with dynamic frameworks, and it also considers generic resources as well. This presupposes the existence of a bundling solution supported in Linux and macOS. IMO before we consider implementing support for dynamic binary artifacts, this needs to be resolved. It sounds like this particular aspect should be discussed in Swift PM, Bundles and Resources - #36 by nacho4d. Note: this is not a requirement for implementing static artifact support.

In my opinion, these are 3 different and major aspects for support for binary dependencies, and each should have a separate pitch, otherwise we'll just talk over each other and following the discussion will become hard (potentially discouraging other members of the community from participating).

Note that the designs/pitches for API for Package.swift and Format for the artifact/artifact manifest can happen in parallel, but before the implementation phase can start, a solution for runtime dependencies needs to happen first.

1 Like