SE-0208 Package Manager System Library Targets

Hello Swift community,

The review of SE-0208 “Package Manager System Library Targets" begins now and runs through April 13, 2018.

Reviews are an important part of the Swift evolution process. All reviews should be made in this thread on the Swift forums or, if you would like to keep your feedback private, directly in email to me as the review manager.

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages, libraries, or package managers 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?

More information about the Swift evolution process is available on the Swift Evolution website.

As always, thank you for participating in Swift Evolution.

Boris Buegling
Review Manager

4 Likes

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?

Yes, requiring system module package declarations to be in separate repositories is problematic.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?

Nope.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal. Also, I have experience with using system module package declarations.

What is your evaluation of the proposal?

Strong +1.

Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?

Yes, clearly.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?

No.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Reading the proposal and the experience with the described problem.

Having read the proposal, although with admittedly little prior knowledge of the Swift Package Manager, I do support it. The issue being addressed by the proposal is significant, fits in with the overall Swift language, and is a logical and beneficial move for Swift users. So, overall +1.

I agree with it!

Yes. the sheer number of empty zlib packages floating around github is a testament to that

yes

Yes, C. this proposal will create a much more user-friendly interface than the C one though

I read the whole thing through and I’ve been asking for this feature for a while

+1

Yes, creating individual repositories for each system library is cumbersome and I haven’t seen a wide variety of system libraries offered by community repositories.

Yes, it fits in naturally with Package.swift.

I haven’t used any other package managers with this feature.

I read the full proposal

One my concerns is that any c library that gets a Swift wrapper will now be specifically attached to a larger Swift dependency. Let me give an example of what I am trying to say. Vapor has a dependency CTLS that basically packages the C library for use with SPM. With this proposal I am guessing that would move into the Swift package that directly uses it (Engine?) which seems like a nice thing. However what if others would like to use that wrapper as well they would now have to pull in Engine as well? This seems like it could be solved in the future with multiple packages per repository but that also would seem to make this proposal less useful because the problems this is trying to solve would be solved?

i still don't get what you're saying,, the point of this is that there would be no need for wrapper packages like that in the first place

Exactly removing the need for them makes them go away basically meaning anyone wanting to use a C library has to do the same work that someone else has prob already done but is now attached to their Package you don’t want to depend on

It is the same work but instead of adding a dependency to your Package.swift (which requires creating a dummy package), you add directly the system target.

1 Like

TL;DR: +1 to this proposal. It should not create any issues that are not already an issue today (conflicting module names). However, it would be nice to see a separate proposal for making private targets actually be private.

@kdawgwilk, If I understand your concern correctly, you are concerned that multiple packages will create private targets referencing the same C library.

I think this will indeed be a problem iff the targets use an identical name. IIRC, SPM does not support two dependencies that have modules with overlapping names even if none of those targets are exposed as products. However, that's a problem even currently and has a pretty simple solution. The solution is that any private (non-product) modules should have their names be sufficiently unique or namespaced. For example, NIO prefixes all of their C library targets with CNIO. (swift-nio-ssl/Package.swift at main · apple/swift-nio-ssl · GitHub).

A better solution (not sure if this is even possible) would be for SPM to allow dependencies to contain modules with identical names as long as they are private. In other words, module name conflicts will only happen for public targets (targets added to the products array). SPM could implement this internally by prefixing private targets with the package name or some other unique string.

I don't think we can implement this in a non-leaky way without compiler support. Target names have to be unique because module names have to be unique and if we would prefix them, then users would also have to change their import statements.

I'm not sure I understand why this proposal changes the situation for packages which are essentially bindings.

Right now, a package needing an existing system-level C library would need to create a system package and a bindings package (or the bindings could be only a target). This proposal eliminates the system package, but whether or not a separate bindings package is created doesn't change.

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?

Yes. The proliferation of modules that exist only to cause linking and inclusion of symbols for system libraries is getting a little bit silly, but will never stop. It is easier, in most cases, to manufacture such a package than it is to go trying to find one that works for you.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?

About the same, maybe slightly better. It's nicer than most of Python's equivalent behaviours, and arguably about the same as the higher-level toolchains like cffi.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, implemented a substantial amount of code that uses system modules.

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?

Yes

Does this proposal fit well with the feel and direction of Swift?

Yes, It'll make creating packages with system package easier.

If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?

No, (Ruby, Python, Erlang) doesn't need to declare a target when using FFI.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read of the proposal. Created several packages depends on system packages.

The review of SE-0208 “Package Manager System Library Targets" ran from April 6…13. Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!

Boris
Review Manager

1 Like