[Review] SE-0063: SwiftPM System Module Search Paths


(Anders Bertelrud) #1

Hello Swift community,

A review of "SwiftPM System Module Search Paths" for the Swift Package Manager begins now and runs through Wednesday, April 13th.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

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 the Swift Package Manager?
  * If you have you used other 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 at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Anders
Review Manager


(Ankit Agarwal) #2

        * What is your evaluation of the proposal?

I am in favour of this proposal. It will solve an important problem faced
by swiftpm users.

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

Yes, system modules often require extra flags and search paths are platform
dependent. A lot of users have reported bugs in jira about this.

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

Yes, it will improve the functionality of swiftpm

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

I implemented the first draft of proposal and tried using GTK3 library on
OSX and Ubuntu, It works out really nice. More info about the experiment :
http://ankit.im/swift/2016/03/26/improving-system-modules-support-in-swiftpm/

···

--
Ankit


(Daniel Dunbar) #3

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?

I think it is a good direction.

I think we inevitably will need to interface more with system package managers in order to do a great job of being seamless and working out of the box, and while the addition of "providers" to the Package.swift is going to have a maintenance cost, it seems sensible to go ahead and start building out this support. This design also allows the community to effective contribute a lot of the information on the package name correspondence.

The one thing I feel the proposal lacks currently is how tag versioning information in the Swift package is going to correspond to the underlying system package. My expectation is that we probably want Swift system packages to try and adopt a versioning scheme which matches that of the underlying system package.

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

Yes, this is a common initial pain point with using system modules, and will make it easier to understand the behavior in the context of other system package tools and standard project development environments (e.g., autoconf projects).

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

I think it fits well, the intention is to

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

Not in this form.

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

In-depth study.

- Daniel

···

On Apr 7, 2016, at 1:14 PM, Anders Bertelrud via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

Anders
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Max Howell) #4

The one thing I feel the proposal lacks currently is how tag versioning information in the Swift package is going to correspond to the underlying system package. My expectation is that we probably want Swift system packages to try and adopt a versioning scheme which matches that of the underlying system package.

This is already implemented as a recommendation for the user to use “best judgement” so strictly was not required in the proposal. But best judgement is certainly not enough detail.

The reason we did not initially say: use the same version as the system package is:

* you may need to bump the SwiftPM package independently of the system package version


(Max Howell) #5

The one thing I feel the proposal lacks currently is how tag versioning information in the Swift package is going to correspond to the underlying system package. My expectation is that we probably want Swift system packages to try and adopt a versioning scheme which matches that of the underlying system package.

This is already implemented as a recommendation for the user to use “best judgement” so strictly was not required in the proposal. But best judgement is certainly not enough detail.

s/Implemented/Documented: https://github.com/apple/swift-package-manager/blob/master/Documentation/SystemModules.md#module-map-versioning