I'm trying to find out how to update the version of locally installed dependencies to match the Package.resolved file, similar to how carthage bootstrap --use-cache and yarn install work.
For example, if I have version 1.0.0 installed, then pull a change that updates the version to 1.1.0 in Package.resolved, what can I run to install 1.1.0?
Currently I am deleting the .build directory, but this deletes all dependencies, which means already up-to-date dependencies must be rebuilt.
I tried swift package resolve, but this updates the Package.resolved file to match the locally installed dependencies.
This works when the version in Package.resolved has the latest version, but not when it is behind, e.g. Package.resolved has version 1.0.0, but the latest available is 1.1.0.
This could be an issue if, for example, CI is set to fail builds with warnings and the dependency deprecated a function in 1.1.0 while development was done against 1.0.0.
An alternative I see is to use .exact("1.0.0") in my Package.swift, but then swift package update will not update this dependency.
swift package resolve should already do this unless the requirements in your Package.swift are also changing. It sounds like a bug if it’s not working for you.
I was expecting swift package resolve to work this way, so maybe I'm doing something wrong, or this is a bug. Essentially what I'm doing is:
No .build directory, from: "1.0.0" in Package.swift
swift build
I now version 1.0.0 compiled in the .build directory and 1.0.0 in Package.resolved
Dependency releases 1.1.0
Run swift package update on another computer, commit and push change to Package.resolved
Pull the commit that updates Package.resolved to have version 1.1.0
swift package resolve
Package.resolved now has 1.0.0 in it, essentially reverting the pulled commit
What I'm doing is actually 1.3.2 => 1.5.4 of danger-swift, so it's a little more complex, but I can try and provide a more basic setup in a .zip if you still think this could be a bug?
