[swift-build-dev] [swift-evolution] Proposal: Package Manager Version Pinning

[Eloy Durán]

>> Totally 👍
> 
> I'm not sure what this is to. :)

You and me both… Guess I must have lost track of my thought here while trying to respond from my phone and playing with the baby in between.

> Pin by default in the sense you are using it just means we automatically would create "Package.pins", that is the only behavior change (i.e., you don't inherit it from your dependencies).
> 
> Can you explain why simply needing to run one more command when you want to do this is a big deal?

It’s clearly not a big deal in amount of work, what it comes down to is setting an example. If you, as an authority, make it the default option to not pin, then to many people that will signal that that’s The Right Thing to do.

> Is it possible that we have a different expectation about what the tools do when you don't create this file?

No, it’s a philosophical difference in thinking about dependencies.

I see it as my responsibility to know exactly what code I’m pulling into my package. In my view, it’s absolutely unsafe to trust other people’s code. Even when they mean no harm, trusting them to properly apply SemVer is the same issue.

My worst nightmare is people updating dependencies and getting lazy in vetting them, a mindset that is in my observation the status quo in e.g. npm, a dependency manager which makes it the default to not pin and trust SemVer. On the other hand, the laziness might also be compounded by the micro-lib norm, it’s not unusual for npm packages to have a dependency graph of dozens, if not hundreds of packages.

This also leads me to the following point you bring up:

> One argument I haven't heard anyone refute is that we can always back down from this position, but the converse isn't true (because its impact will have permeated the ecosystem). I consider that an important point.

The reason I would not try to refute it is A) simply because it’s true and B) it’s, to me, more of a technicality that’s moot in contrast to my philosophical thoughts, as explained above.

One final note, playing the devil’s advocate against my own opinion, seeing as you are at a place where you can try it and later change, I’d say do it. However, it might be a good idea to document the possibility of this changing in the future, just so expectations are set correct and the thought to keep an eye on this is kept alive in the community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161014/cace8ddd/attachment.html>