[swift-evolution] [Review] SE-0145: Package Manager Version Pinning

[Daniel Duan]

> 
> 	* What is your evaluation of the proposal?

+1

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

Yes, version pinning is very important to dependency management in production environments.

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

Yes.

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

I have used various dependency management systems and had seen some evolving in particular domains (pip’s eventual emergence over the last decade in Python land comes to mind. Linux package managers as found in Debian/CentOS/Arch/Gentoo, albeit less analogous here). Ruby gems, Cocoapods and Carthage are the ones I’m using in production today.

Excluding a few cosmetic differences (.pins extensions, whether to automatically pin, pinning commands etc), the proposed mechanisms are actually very similar to the ones we know and love in iOS/macOS development today: there’s some remote sources where the dependencies reside, most likely version controlled repositories with explicit ways to identify a certain state in their history. Using a text file to record the state identifiers, the manager can ensure shared, reproducible building environment. No surprise here.

As for the difference: I can’t recall a time when I really thought about the file extension of Podfile.lock or Carthage.resolved or Gems.WhatEverTheHeck. The proposal had dedicated a good potion to explain the choice of .pins, that deserves some extra credit IMHO. Explicit pinning commands gives us more control. In a team environment, if you are using a pinning feature, it’s *really* annoying to have accidentally triggers a change in the .lock/.resolved files. This is happens when your team opt-out a latest version of the dependency. Automatic pinning, therefore, is not a feature, it’s the lack of one.


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

Read initial draft of the proposal and its discussions. Read the actual proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161102/4e438e7f/attachment.html>