[Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

Evolution Discussion
1

Hello Swift community,

The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:

  swift-evolution/0135-package-manager-support-for-differentiating-packages-by-swift-version.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  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 contribute to 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 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?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

- Daniel Dunbar
Review Manager

2

Hi Daniel,

I hope this proposal really is still in active review, as it is marked as such in the swift-evolution Git repository.

I did a quick reading of this proposal and I like it very much. I think that it provides a solution that is additive and doesn't break any existing package specifications.

With the amount of source-breaking changes in Swift, I think this proposal is really important and I hope that it still will be implemented in Swift 3 timeframe. Especially as SwiftPM is not as tightly coupled with the core compiler infrastructure, this would be a good timing to introduce this to help people in transitioning from Swift 2.2 to Swift 3.

Have you previously considered also adding a field to manifests, that will allow to declare the supported version in the dependency manifest itself? As in:

let package =
Package(
    name: "Foo",
    swiftVersions: ["3.0", "2.1"]
)

This would make it impossible to even try to build this module with Swift 2.1, thus saving time by not doing a build that will inevitably fail. This would also help packages supporting both versions in the same source tree with #ifdef swift version conditionals. I do realise that my suggestion will not be considered for Swift 3, but I look forward to your feedback on this.

Thanks!

···

---
With best regards, Max.

On 29 Jul 2016, at 21:36, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

Hello Swift community,

The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  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 contribute to 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 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?

More information about the Swift evolution process is available at

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

Thank you,

- Daniel Dunbar
Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

3

I appreciate that I'm late on this, but I'm on vacation.

Hello Swift community,

The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  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 contribute to 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?

The solution is quite clear. I particularly like the concept of version specific git tags. I'm less keen on version specific Package.swift files as I feel that tags are meta data, but Package.swift isn't.

Personally, I'd prefer to only have version specific git tags, but acknowledge that version-specific Package.swift files simplify the work for some package maintainers. If you need different source code in Package.swift and if doesn't work, then I feel that you should use version specific git tags as you would do for the rest of your code.

I'm pleased that this proposal is backwards compatible as both options can be completely ignored for packages that don't need it.

On the whole, +1.

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

Most definitely.

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

It certainly acknowledges the current state of Swift language differences :)

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

This is quite elegant and more flexible than what I've seen elsewhere.

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

I read the proposal in detail.

Regards,

Rob..

···

On 29 Jul 2016, at 20:36, Daniel Dunbar via swift-evolution <swift-evolution@swift.org> wrote:

4

Hi Max,

Hi Daniel,

I hope this proposal really is still in active review, as it is marked as such in the swift-evolution Git repository.

It was supposed to close yesterday, but I haven't gotten to the paperwork. We have received very little feedback on the proposal so I appreciate your reply.

I did a quick reading of this proposal and I like it very much. I think that it provides a solution that is additive and doesn't break any existing package specifications.

With the amount of source-breaking changes in Swift, I think this proposal is really important and I hope that it still will be implemented in Swift 3 timeframe. Especially as SwiftPM is not as tightly coupled with the core compiler infrastructure, this would be a good timing to introduce this to help people in transitioning from Swift 2.2 to Swift 3.

Have you previously considered also adding a field to manifests, that will allow to declare the supported version in the dependency manifest itself? As in:

We did consider this, but it has two major problems:

1. The list is cumbersome to maintain, particularly when the expectation is that new Swift versions do not break the package, and thus it remains compatible. A feature like this has the problem that once added, it requires maintenance in every package even once it has outlived its utility: As long as some package is used by SwiftPM-3.0 it has to keep the annotations, even if just to tell that version to look elsewhere.

2. This doesn't handle situations where we change the APIs within the manifest itself -- older SwiftPM versions won't be able to parse them and won't know what to do.

- Daniel

···

On Aug 4, 2016, at 6:46 AM, Max Desiatov <max.desiatov@gmail.com> wrote:

let package =
Package(
   name: "Foo",
   swiftVersions: ["3.0", "2.1"]
)

This would make it impossible to even try to build this module with Swift 2.1, thus saving time by not doing a build that will inevitably fail. This would also help packages supporting both versions in the same source tree with #ifdef swift version conditionals. I do realise that my suggestion will not be considered for Swift 3, but I look forward to your feedback on this.

Thanks!

---
With best regards, Max.

On 29 Jul 2016, at 21:36, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

Hello Swift community,

The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  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 contribute to 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 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?

More information about the Swift evolution process is available at

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

Thank you,

- Daniel Dunbar
Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

5

Also: In discussing this, we also considered doing something like putting the version number in a comment line at the very top of the `Package.swift`, so that it could always be string-searched even in cases in which a new-format manifest isn't parseable by an older SwiftPM.

But that feels quite hacky, and we didn't want to do that if we could avoid it. For one thing, we want to make newly created packages that support just the latest Swift not start out with a bunch of cruft in the form of specially formatted comments etc. And secondly, well, it's just ugly.

Anders

···

On 2016-08-04, at 08.57, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

2. This doesn't handle situations where we change the APIs within the manifest itself -- older SwiftPM versions won't be able to parse them and won't know what to do.

6

I appreciate that I'm late on this, but I'm on vacation.

Thanks for the response, I'm glad to be getting some additional feedback.

Hello Swift community,

The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  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 contribute to 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?

The solution is quite clear. I particularly like the concept of version specific git tags. I'm less keen on version specific Package.swift files as I feel that tags are meta data, but Package.swift isn't.

Personally, I'd prefer to only have version specific git tags, but acknowledge that version-specific Package.swift files simplify the work for some package maintainers. If you need different source code in Package.swift and if doesn't work, then I feel that you should use version specific git tags as you would do for the rest of your code.

One primary motivation here was we wanted to encourage the use of packages which work across all modern Swift versions. That doesn't work out too well once you move to version specific tags if you are actively maintaining the compatibility as you would need to constantly retag and update Package.swift across the "branches" for each new version. We do agree it is unfortunate... the hope is this problem will go away quickly once the manifest API stabilizes.

- Daniel

···

On Aug 4, 2016, at 9:16 AM, Rob Allen <rob@akrabat.com> wrote:

On 29 Jul 2016, at 20:36, Daniel Dunbar via swift-evolution <swift-evolution@swift.org> wrote:

I'm pleased that this proposal is backwards compatible as both options can be completely ignored for packages that don't need it.

On the whole, +1.

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

Most definitely.

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

It certainly acknowledges the current state of Swift language differences :)

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

This is quite elegant and more flexible than what I've seen elsewhere.

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

I read the proposal in detail.

Regards,

Rob..