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

[Rick Ballard]

> The review of SE-0152 "Package Manager Tools Version" begins now and runs through February 13, 2017.  The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md <https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md>
Hi Will,

Thanks for taking the time to review this.

Is there a particular reason you're envisioning that we might need to extend the metadata for the Swift tools version?

We've left ourself an escape hatch in case we ever do need to, where anything after a  ';' character in the tools version comment will be ignored for now, but I'm not expecting that we'll ever need to use that escape hatch. The Swift tools version itself needs to be stored in a special way since it dictates how we'll interpret the manifest, but once we've determined that, all other data should be able to be stored as Swift code in the manifest as per usual.

If you can think of some good reasons why we'd actually need this extensibility, please do suggest them. Otherwise I'd hope that we wouldn't need to choose a less convenient mechanism here for the sake of more convenient extensibility that will likely never be used.

Thanks,

	- Rick

> On Feb 8, 2017, at 10:49 AM, Will Field-Thompson via swift-evolution <swift-evolution at swift.org> wrote:
> 
>  
> 	*  What is your evaluation of the proposal?
> 
> I fully support the goals of the proposal and have a question about the implementation.
> 
> 	*  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 Package.swift.
> 
> 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-build-dev/attachments/20170208/e3470350/attachment.html>