> On Oct 14, 2016, at 10:37 AM, Huon Wilson via swift-evolution
> <email@example.com> wrote:
>> On Oct 14, 2016, at 09:43, Alexis via swift-evolution
>> <firstname.lastname@example.org <mailto:email@example.com>> 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
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.
> swift-evolution mailing list
swift-evolution mailing list