> On 3 Nov 2016, at 17:36, Daniel Duan via swift-evolution > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
