[swift-evolution] SE-0152: Package Manager Tools Version

Will Field-Thompson will.a.ft at gmail.com
Wed Feb 8 12:49:38 CST 2017

> *  What is your evaluation of the proposal?

I fully support the goals of the proposal and have a question about the

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

Yep. It provides a good way to evolve the API, and putting it in place for
Swift 3.1 gives us the freedom to evolve the API as (or if) needed for
Swift 4.

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

I agree that the placement of the tools version in a comment is
unfortunate, but I think that it's the best way to include it in

I'm interested in other people's thoughts on a .swift-tools-version file.
I'm not sure I prefer it to the comment in Package.swift, but the reasons
included in the proposal don't convince me the .swift-tools-version shouldn't
be used either.

   - *Eliminates the possibility of including either Package.swift or
   .swift-tools-version*: Seems like exactly the kind of mistake you make
   once and then don't make again. I guess with a leading dot it's more likely
   to be forgotten than a non-dot-file, but not a major issue IMO.
   - *Users may like to see the version in the Package.swift*: Probably
   true, though I'm not sure how much of an issue it is.

Are these significant problems for other people? They don't seem that way
to me, but I may not represent the majority here as my work is in iOS dev
and the only time I get to use swiftpm is for side projects.

The .swift-tools-version has the advantage that it is extendable in a
prettier (i.e. easier to read and easier to diff for VCS purposes) way than
the semicolon-separated syntax from the proposal. How likely is it that
we'll ever have to extend it? I think that, for me, is the determining
factor for which format I prefer.

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

The main package manager I use is CocoaPods and as far as I am aware
CocoaPods doesn't allow you to specify the tools version in the Podfile.
This did cause some (albeit minimal) pain on transition to CocoaPods 1.0. I
think Podfile.lock records the version of CocoaPods, but I don't think that
actually helps in this regard.

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

I spent some time reading through the proposal, but I lost track of the
discussion pre-proposal.

- Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170208/84c2b2a3/attachment.html>

More information about the swift-evolution mailing list