v3: Drop architecture from layer names? #311

(A thought for Bref v3 #257, which I can see is already enjoying some layer amalgamation…)

The CompatibleArchitectures property may further help to reduce the combinatorial explosion… albeit with trade-offs.

Lambda allows us to publish arm64 and x86_64 versions with the same layer name, and then list versions with a filter on the architecture, e.g.

publish-layer-version --layer-name php-84 --compatible-runtimes provided.al2 --compatible-architectures x86_64 --zip-file fileb://php84.x86_64.zip
# creates version 21

publish-layer-version --layer-name php-84 --compatible-runtimes provided.al2 --compatible-architectures arm64 --zip-file fileb://php84.arm64.zip
# creates version 22

lambda list-layer-versions --layer-name php-84 --compatible-architecture x86_64
# lists only version 21

A theoretically sensible service that didn't require version specification (not you, Lambda) could use the most recent version with contextually appropriate runtime and architecture by default.

I figure you construct and distribution layers.json because querying AWS when required is fraught with permission challenges? This approach would mean changing layers.json to a map of layer¹ to region to architecture to version.

(btw, Bref doesn't currently set the compatible architecture property at all, which makes it slightly easier to build a Lambda that will fail at runtime.)