> On Nov 4, 2016, at 9:06 AM, Paul Cantrell via swift-evolution > <[email protected]> wrote: > > I’ve used bundler, Carthage, and CocoaPods extensively. All of them always > generate a lockfile (Gemfile.lock, Cartfile.resolved, and Podfile.lock). All > of them use these files as the unique mechanism for version locking, and all > use version control of that file as the unique mechanism for controlling > whether to locked versions are shared across teams. > > We have many years of evidence that this model works well. > > Note that all of these package managers also work in in environments that do > not support using multiple versions of a dependency in the same artifact at > the same time. Therefore this statement from the proposal: > >> 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. > > — > > I’ve also used npm and bower, which either do not have version locking or > only provide it via add-ons. It’s a nightmare. Lack of locking has caused > headaches and lost hours — not hypothetic headaches, but real ones on actual > projects — in two scenarios: > > 1. onboarding new developers who get fresh, incompatible dependency versions > on initial checkout; and > 2. picking projects back up for a new round of development. > > Are these two situations really the right time for people to accidentally > test whether their dependencies have properly followed semantic versioning? > No. There are better ways, and better times. I am troubled by the insistence > on ignoring experience here. However, as I said above, I’m willing to give it > a try. I will keep an open mind in the name of bold experimentation, and > would be happy to have my concerns proven wrong. > > Please do keep in mind, however, that this is an experiment. Be ready for all > that careful theorizing to be falsified by experience. You may have to murder > this darling: > http://www.slate.com/blogs/browbeat/2013/10/18/_kill_your_darlings_writing_advice_what_writer_really_said_to_murder_your.html
Thank you for articulating this, Paul. Personally, I think we have all the evidence we need--including languages that have tried both and settled on pin-by-default--to know how this will turn out. But if the default is to not pin, I can simply write a `fish` function to shorthand the pinning commands and forget about this issue. No big deal. I'm also less agnostic about the "pin" vs. "lock" question: I think "lock" is nearly universal prior art and we ought to stick to it. However, it's ultimately just a name. People will figure it out. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
