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

[Paul Cantrell]

> On Nov 4, 2016, at 11:20 AM, Boris Buegling <bbuegling at apple.com> wrote:
> 
>> On 4 Nov 2016, at 17:06, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> Overconstraint is much more of a risk in Swift than in other languages using this style of package management.
>> 
>> …is incorrect.
>> 
>> In particular, note that Ruby does not support using multiple versions of a lib simultaneously, and that fact alone — even in the presence of _ubiquitous_ version pinning — has been sufficient to encourage widespread mindfulness about semver compliance. All of the concerns expressed in the “Pin by default” section of the proposal also apply to Ruby, and have failed to materialize there.
> 
> Note that this only partially true. It is strongly recommended to not check in your Gemfile.lock when developing a gem (see http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/), but only when you’re developing an app. This means that pinning by default is effectively not performed when doing library development in the Ruby ecosystem.


If SwiftPM used that bundler-like behavior, then presumably the same recommendations about what to check in would apply. By “ubiquitous version pinning,” I mean that the package management tool _always_ generates a lock file, and developers decide for themselves how to manage it.

That section in the proposal made the argument that Swift is fundamentally different from other languages in ways that make always generating a pins file uniquely dangerous. That is false.

Cheers, P