[swift-build-dev] [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

Paul Cantrell cantrell at pobox.com
Mon Dec 5 22:09:19 CST 2016

> On Dec 2, 2016, at 11:11 AM, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
>> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> This version of the proposal seems acceptable to me, though I have a nagging feel that it’s more complex than it needs to be.
> I agree with this feeling, but am not sure how much it will matter in practice.

As I said in my review, I suspect it will confuse newcomers and lead to a few much-duplicated questions on Stack Overflow, but not hurt teams whose workflow is already established. One-time cost, not so bad.

>> AFAICT, the one thing this simpler model wouldn’t allow is for a team to share pinned versions of some individual ill-behaved dependencies without pinning all of them. If that’s the only missing behavior, my gut tells me there’s a way to do that with less cognitive burden on SwiftPM users.
> This is a benefit I *really* want to retain, because we continue to feel it is important for people not to overly constraint the dependency graph, and I still feel this is the right model for users to follow (pin problematic dependencies, not everything). I really want to retain the technical ability to do it, even if it is off by default.


> If you have a concrete proposal on a better way to implement this I would love to hear it.

I chewed this over, and sketched out a variant that I thought was simpler. I then realized that what I came up with is basically identical to the existing proposal, except:

1. I renamed `--enable-autopin` to `pin --new`.
2. It doesn’t have the convenience of new requiring `--repin` if everything is already pinned.

At least I _think_ what I came up with is nearly identical. Here it is in case you want to check me on that:


> At this point, what I want to do is get this implemented and in a usable state, and then gauge how problematic this behavior difference is. If it is a source of confusion, then we should iterate to try and address it.

Agreed! This is a fine starting point.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161205/42168b6a/attachment.html>

More information about the swift-build-dev mailing list