packaging plugin

[tomerd]

motivation: an easy way to archive lambda for uploading to AWS

changes:

• add SwiftPM plugin with the verb "archive"
• on Amazon Linux, build and package directly using the plugin bridge into SwiftPM
• on other platforms use docker to build and package the lambda(s)

[tomerd]

cc @abertelrud - this requires escaping the sandbox because of docker. would appreciate your feedback on the direction here

[tomerd]

@fabianfett I think this is ready to merge as iteration 1. next iteration we can explore how to integrate ziplib

[tomerd]

I think we should at least print the processes output

fixed

[fabianfett]

Interesting, just pulled the newest version and tried to rerun:

➜  Echo git:(feature/packaging-plugin) ✗ swift package archive
-------------------------------------------------------------------------
building "echo" in docker
-------------------------------------------------------------------------
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: operation not permitted.
See 'docker run --help'.
error: /usr/local/bin/docker run --rm -v /Users/fabian/Developer/swift-server/swift-aws-lambda-runtime/Examples/Echo:/workspace -w /workspace swift:amazonlinux2 bash -cl swift build -c release --show-bin-path failed with code 126
➜  Echo git:(feature/packaging-plugin) ✗ docker container create swift:5.6-focal
98decac8da409010202c45428d18e06f9761f1b130c649afc14778b6d74aa72b
➜  Echo git:(feature/packaging-plugin) ✗ 

Apparently from the plugin I don't have enough rights to create a new container, but just from the shell I have. Do you have any idea what this might be related to @tomerd.

[stevapple]

I think the reason’s here: https://github.com/apple/swift-evolution/blob/55f9bb7eab8e89bb8cd2794083aba101ac07777a/proposals/0303-swiftpm-extensible-build-tools.md?plain=1#L1018-L1020

Wonder if we can surpass the restriction.

[tomerd]

right, this is because talking to docker is networking which is denied by the sandbox. for local testing I have been using the plugin without the sandbox, e.g: swift package --disable-sandbox --package-path Examples/Echo archive

@abertelrud would be interesting to see if we can poke a hole for docker in the sandbox, or be able to express it as a plugin requirement that the user can approve

[fabianfett]

Trying to use this branch with Xcode 13.3 or on the Swift 5.6 cli on macOS results in the following error:

the package manifest at '/Package@swift-5.5.swift' cannot be accessed (InternalError(description: "Internal error. Please file a bug at https://bugs.swift.org with this info. symlinks not supported")) in https://github.com/tomerd/swift-aws-lambda-runtime.git

➜  foo-project git:(main) ✗ swift --version
swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
Target: arm64-apple-macosx12.0

[fabianfett]

Reading a bit into this... Isn't the way we currently try to solve this the wrong way around?

In case the current Swift version doesn't match any version-specific manifest, the package manager will pick the manifest with the most compatible tools version. For example, if there are three manifests:

• Package.swift (tools version 3.0)
• Package@swift-4.swift (tools version 4.0)
• Package@swift-4.2.swift (tools version 4.2)

The package manager will pick Package.swift on Swift 3, Package@swift-4.swift on Swift 4, and Package@swift-4.2.swift on Swift 4.2 and above because its tools version will be most compatible with future version of the package manager.

https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#version-specific-manifest-selection

If I understand the docu correctly it should work like this:

• Package.swift (for everything older than Swift 5.6)
• Package@swift-5.6.swift (for 5.6 and above)

This way we don't need an extra file for Swift 5.5.

[tomerd]

@fabianfett ?