[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.
Understood.
> 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:
https://gist.github.com/pcantrell/10cf1cc2cc2d8f1b5011e0ea5f828402
> 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.
Cheers,
Paul
-------------- 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