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

[Daniel Dunbar]

> On Oct 14, 2016, at 10:37 AM, Huon Wilson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Oct 14, 2016, at 09:43, Alexis via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> A library shouldn’t pin its dependencies, while an application should.
> 
> Not only “shouldn’t” but can’t: Rust’s cargo (I don’t know for sure about Bundler and Yarn, but they’re all in the same vein, and pretty much from the same person) will just ignore any non-top-level lock files, i.e. the package that user is working on has a record of the exact versions of everything in their dependency graph, and the user can update all or just parts of that graph fairly precisely, as desired.
> 
> My impression is that other ecosystems without pinning-by-default have seriously suffered from the lack of reliable reproducible builds. For instance, a major complaint I have seen about "go get” is that one can come back to some code after a few months to fix a minor bug and have no chance of getting the code to compile, basically just requiring a full rewrite, because dependencies' code has changed (or disappeared entirely) and there’s no record of what the original was, despite your code being completely untouched in all that time.

This wouldn't have been our behavior under this proposal, unless you recloned the package. Maybe that is what you meant though?

> Of course, a hard push towards API-level semantic versioning may allay the worst of the code-changing problems, but unless there’s going to be some seriously fancy static analysis (something something halting problem), there will be a lot of breaking changes that can’t be picked up.
> 
> ---
> 
> To reframe the discussion slightly, not pinning dependencies effectively means that the tools are making “random" changes to your code outside your control. Sure, those changes were transitively made by possibly-computer-assisted humans and may fix bugs, but those pesky meat-bags can still make mistakes, and, they don’t see the interactions between all the different packages in your specific application.
> 
> IME having the predictability of “never changing code under my feet” combined with pervasive semantic versioning hits an empowering middle ground of being able to depend on many & varied packages and update them to the latest versions without fear (for one, it’s easy to revert the lock file if something breaks during an update). Feedback from others about cargo is the same, often along the lines of “it’s the best package manager I’ve ever used”.

To be clear, exactly when are you expecting the tools to "change code under my feet".

In our design, the only time we ever change a *local build* is in response to an explicit user action, so we aren't changing code under your feet necessarily.

If you throw away a checkout, and fetch it again, then yes we get a different version. Is this the use case you are talking about (and by implication talking about committing the file)?

If you reset your local workspace completely, then yes we will get a different version (since we had to reclone).

I just want to make sure it is clear to everyone that we are not proposing we automatically change your build version underneath you any time we happen to fetch something new from the package. We only update in response to user action.

> Also, more on the side of implementation details, having a lock file by default probably mean one can (get closer to) never hitting the network unless the user asks for it, making working offline or on a low-speed/high-latency connection easier, i.e. no need to check for new versions of the whole dependency graph on O(every) build, which aggressively keeping everything up to date would seemingly have to do? (I don’t know swift-pm’s current behavior here, so maybe there’s some tricks that avoid it.)

This is part of the proposed design (this is the current implementation, really), FWIW, although that may not have been clear at all.

 - Daniel

> 
> Huon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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