SE-0305 (2nd review): Package Manager Binary Target Improvements

Evolution Proposal Reviews
1

The second review of SE-0305: Package Manager Binary Target Improvements, begins now and runs through April 21th, 2021.

The feedback from the first review was positive, and the proposal has been amended to address the feedback provided by the community and the core team. It is now ready for a second review.

--

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums).

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thank you for helping improve the Swift programming language and ecosystem.

Tom Doron
Review Manager

4 Likes
2

It’s really cool. +1
The future directions are inspiring and promising. I think the design of archivebundle is flexible enough to bear a bunch of upcoming extensions.

1 Like
3

This seems like a reasonable design, thanks folks. My only suggestions are editorial nits: it might be better to replace the -linux- stanza in the hypothetical linux architecture triple with linux-gnu, which is the common way to indicate that you mean "Linux with glibc".

Otherwise, I am +1 on this, nice work!

4 Likes
4

Thanks for pointing that out @lukasa, I'll amend that when/if the proposal is accepted.

Just so I'm sure I understand what you mean: are you referring to the protoc-3.15.6-linux-x86_64 subpath in:

path: protoc-3.15.6-linux-x86_64/bin/protoc,
supportedTriples: [x86_64-unknown-linux-gnu]

?

5

Yes, that's correct.

6

This might be a big ask, but can artifact bundle manifests be written in Swift instead, like Package.swift?

7

Great, thanks for confirming. To keep it realistic I had actually kept the name exactly as it was in https://github.com/protocolbuffers/protobuf/releases/download/v3.15.8/protoc-3.15.8-linux-x86_64.zip but it can definitely cause confusion. I'll address it in the amendments. Thanks!

8

That's an interesting idea. I would be a bit concerned about the complexity that would introduce, since it would involve defining a new API for that script to use to declare the various artifacts.

What kinds of things would you want to express dynamically in a script? i.e. what parameters would you want to conditionalize on, and for what kinds of choices would a script be used?

9

I’m pleased with how this revision has turned out. I think this is a nice improvement that solves a significant use case for Swift packages. I reviewed the previous version and carefully read through the diff for this revision.

10

I didn't think very deep when I asked the question, and my only experience with binary target is as an end user.

When I read the structure of the manifest,

{
    "schemaVersion": "1.0",
    "artifacts": {
        "<identifier>": {
            "version": "<version number>",
            "type": "executable",
            "variants": [
                {
                    "path": "<relative-path-to-executable>",
                    "supportedTriples": [ "<triple1>", ... ]
                },
                ...
            ]
        },
        ...
    }
}

the "type": "executable" pair reminded me of Product.executable. And I was thinking if it were written in Swift, with an API like this:

struct Artifact {
    
    enum Type{
        case executable
        ...
    }
    
    struct Variant { ... }
    
    init(
        identifier: String,
        version: String,
        type: Type,
        variants: [Variant]
    )
    
    ...
}

then both the name and the value become more discoverable. And it can possibly eliminate some typo problems like mistyping "executabal" instead of "executable".

I don't have any answer to these questions. I haven't (and haven't planned to) distribute binary targets in Swift packages, so I haven't thought this far.

11

We are extending the review of SE-0305 until April 26 to give the community further opportunity to provide feedback.