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

[Daniel Dunbar]

Thanks everyone who participated in this discussion.

We took the feedback on this thread and went back and created a revised proposal, here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md
which we are putting up for review today:
  https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161031/028579.html

Ultimately, we decided to not actually change any of the proposed behavior, *for now*, because we couldn't come to a consensus about how that should look.

What we *did* do is try and write up much more about (a) the current behavior, and (b) the motivation behind the decisions (for example, the implications of not being able to include multiple versions of the same package in one build).

What we also agreed on was that the main thing we need right now is to implement the *mechanisms* in the proposal, and we didn't want the debate over the policy decision (to create the pin file by default) to side track that. So we decided to continue with the proposal as is, but to also reevaluate the impact of the policy decision in the proposal, in time to adjust it for Swift 4 if we decide the way it has played out in the ecosystem so far isn't as intended.

We also agreed there was room for a workflow component around specifying the "style" of package being developed (final application versus something being primarily developed for use as a dependency), but we didn't want to block implementation of the mechanism on figuring out the right design for that. If we get a design for that, we will also probably use that to change the default policy here.

Please take a look at the new proposal, and see what you think.

Thanks,
 - Daniel

> On Oct 14, 2016, at 4:42 PM, Daniel Dunbar via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Oct 14, 2016, at 4:02 PM, Paul Cantrell <cantrell at pobox.com> wrote:
>> 
>> Sorry for the late arrival to this thread. Comments below…
>> 
>>> On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
>>> 
>>> What this proposal about is in one sense being able to export and share those pins.
>> 
>> This is a crucial and clarifying insight. It should be in the proposal! Near the top.
> 
> Good idea, will incorporate it.
> 
>>> 2. Huon, Alexis, and I all agree we should never *inherit* pins by default.
>> 
>> Indeed. Pins should be only be about sharing specific versions within a development team — not with client packages / apps. What’s pinned in Vegas stays in Vegas. Publishing pins to other projects would be nonsensical.
>> 
>>> 5. Given that many people agree there are two workflows (we ourselves had talked about this a lot when writing the proposal, but didn't put it in), we felt it makes sense to consider adding that as an explicit declaration *somewhere*.
>>> 
>>> @Eloy, @Orta: Suppose we had a semantic notion of which packages were intended to be "top-level" versus used as a dependency, and we chose our defaults accordingly (in this case, we would orient workflows towards pinning by default in the top-level case, in the used as a dependency case we would orient away from it, e.g. warning you if you checked it in). What would you think of such a design?
>> 
>> I’m puzzled. If a package’s pinning does not affect any other package that uses it, why should the defaults be different? A library will still suffer from all the “works for me” problems an app might.
>> 
>> Is the rationale that not pinning libraries encourages accidental testing of new versions of a library’s dependencies as they arrive? Or is there another rationale for having different defaults?
> 
> I'll defer to this comment (linked from someone else earlier in the thread), which happens to match up with my perspective:
>  https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537
> 
> - Daniel
> 
>> 
>> Cheers, P
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution