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

[Boris Buegling]

> On 3 Nov 2016, at 17:36, Daniel Duan via swift-evolution <swift-evolution at swift.org> wrote:
>> I am not sure why in some cases we need to be unique over state of the art like Cocoapods in some areas. What is the added value (not saying that there is none)?
> 
> You can combine mechanisms to get your desired policy: get “pin by default” by always running “pin —all” along side other build steps. The converse isn’t true: you cannot get automatically updated dependencies (often your internal packages) at install without changing and checking in Podfile.lock. This issue manifests even more if you try to not distribute Podfile.lock: you get one anyways after your first install, so you’d have to remember to remove it before the next install).
> 
> (I’m not criticizing the practice of pinning everything by default, just want to point out it’s not flexible for cases where it’s not flexible. No one should decide those cases for anyone!)
> 
> The value added is well explained in the proposal. Simply saying “Cocoapods is good enough, why don’t we copy it” isn’t very constructive and interesting to me.

BTW, CocoaPods does not even have a concept of pinning dependencies for libraries and the pod-template does explicitly not commit the Podfile.lock by default for the generated example. Since library packages are currently the prevalent use case of SwiftPM, not pinning by default is actually very similar to CP’s behaviour.

Cheers,
Boris