[swift-evolution] SE-0152: Package Manager Tools Version
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
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
* 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution