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

[Brent Royal-Gordon]

> On Nov 4, 2016, at 9:06 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> 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