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

[Rob Allen]

> On 14 Oct 2016, at 18:55, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
>> On Oct 14, 2016, at 9:43 AM, Alexis via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> We considered making the pinning behavior default on running swift build, however we think that pinning by default is likely to make the package graph more constrained than it should be. It drives the user away from taking full advantage of semantic versioning. We think it will be good for the package ecosystem if such a restriction is not the default behavior and that this design will lead to faster discovery of bugs and fixes in the upstream.
>> 
>> I agree with the others that this is the better solution.
>> 
>> With regards to the constraining problem, the key insight adopted by Cargo/Yarn/Bundler is to distinguish libraries from applications. A library shouldn’t pin its dependencies, while an application should. This ensures that the ecosystem itself is maximally unconstrained, while ensuring actual applications continue to reliably build, regardless of ecosystem changes and the computer that it was built on. If a version of a library has trouble building with different versions, it should ideally specify that with its dependency constraints, not a lock file.
> 
> This I think is one big crux of the current discussion, and one of the things not in the proposal was my expectation that most packages right now are going to be shared (I personally wouldn't say libraries vs applications, since applications can also be shared as build tools, I think it comes down to whether it is shared or not).
> 
> If we agree that a library shouldn't pin its dependencies, how would you surface this feature? What exact behavior would you prefer?
> 

Bundler, Composer, Cargo & Yarn all ignore the lock file on dependencies and only use the one on the main build target so that they can solve the constraining problem. The final build target lock file does have the list of all exact version required for all the dependencies and sub-dependencies though for deterministic building of the final product. 

This only works because they all take full advantage of semantic versioning anyway.

I particularly like Yehuda Katz's explanation on why it works this way: https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537 

Regards,

Rob...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161014/967c48f0/attachment.html>