Supporting `zip` archives for local binary targets

Development Package Manager
1

In order to improve our build times with the Swift Package Manager, we precompile all our 3rd party dependencies as XCFrameworks to use them as .binaryTargets. We also keep the precompiled frameworks under source control in our repo, so we can reference them from the dependency umbrella package:

let package = Package(
    name: "Dependencies",
    ...
    targets: [
        .binaryTarget(
            name: "ThirdPartyDependency1",
            path: "path-to/third-party-dependency-1.xcframework"           
        ),
        .binaryTarget(
            name: "ThirdPartyDependency2",
            path: "path-to/third-party-dependency-2.xcframework"           
        ),
        ...
    ]
     ...

but, unfortunately, we cannot reference them as zip archives because it is currently possible only for the remote targets, for some reason. Keeping those XCFrameworks unzipped under source control is quite inconvenient because of:

  1. The long diffs on every binary target version update.
  2. Potentially higher fragmentation of the file system.

That's why I believe that supporting zip archives for local binaryTargets is a missing piece of functionality that could be in demand in the community.
What was the reasoning behind that design decision? If there are no fundamental restrictions I would love to provide a PR that fixes that.

2

There wasn't any strong reasoning behind this. Remote XCFrameworks obviously had to be zipped and local ones were supposed to be unzipped for convenience, e.g. while testing. I believe we simply didn't consider the use case of having a local XCFramework be zipped.

1 Like
3

Thanks, Boris! Would you consider this piece of functionality as something you wanted to have? If so, does it need to go through the evolution process, or would it be fine to prepare a direct PR?

4

@NeoNacho Sorry for bothering you again, maybe there is an easy answer to the question above? We would love to contribute if it is possible.

5

I think a PR would be fine for this. But @tomerd might also have opinions on that.

1 Like
6

supporting local archives sounds good to me. PR is welcome!

2 Likes