I'm writing a package that relies on another package that I manage (Netswift). I've setup a bleeding_edge branch there, where I commit every few hours (i.e when I notice access control is wrong, or any other small edit).
Now my current package has a dependency on the github repo for Netswift, with that bleeding_edge branch, as pictured below:
Unfortunately, resolving the dependency graph by any of the following means (updating Package.swift with an empty space somewhere, running swift package update) does not pull new commits from that branch.
The only way I found to force-update is to specify a different branch, resolve dependerency graph, then revert back to the branch I actually need.
resolve attempts to keep the exact same versions and revisions as last time (which are recorded in Package.resolved). That means it will only trigger an update if you have changed the constraints since the last time, so that what you had before is no longer valid. resolve is what build, test, run etc. do implicitly.
update deliberately asks for the whole graph to be evaluated anew, trying to switch to the newest versions or revisions. It throws away Package.resolved and starts over from scratch.
$ swift package update
(Xcode has a similar commands in the menu under File → Swift Packages.)
Also, if you want to work on both packages in tandem, you can do this:
swift package edit Netswift
Then SwiftPM will check out Netswift under Packages/Netswift. At that point SwiftPM is pointing directly at those sources, so you can edit them directly. When you are done, push whatever changes you’ve made in the Packages/Netswift repository and then do this:
swift package unedit Netswift
(Note that if you want to use this strategy with Xcode, you will have to do swift package generate-xcodeproj, because Xcode 11’s direct support for packages ignores edit mode.)
Thanks a lot for the answer, I figured swift package update would do just what you said, but it didn't which is why I was confused. Using the xcode File menu did do the trick, however. I'm curious as to what the difference is...
Reviving this thread, as it’s an issue that my team has been struggling with. We’re working on a large project that uses a mix of third party packages and 6 in-house packages. Some of these in-house packages are pretty active, so we have our package manifest pointing at their respective development branches (develop) instead of a specific version or commit.
When someone on the team is working on one package, dragging a local copy of it into the Xcode workspace works great for editing. However, once those changes are merged back into develop, other folks on the team will try to get those changes using File/Packages/Update Package Versions. At this point, Xcode appears to be doing something, but when it completes, the package hasn’t been updated to the new changes that were just pushed. Using the other commands in Xcode, both Resolve and Reset usually leave us in the same state.
So far, most of the team has ended up just using local copies of the packages dragged into Xcode, but that means we need to manually bounce between each repo pulling changes down. I’ve also tried using xcodebuild with the options to update the packages and ignore the caches, but that’s not very reliable either. I have had success with editing the Package. resolved file to a specific commit, but that’s just a hack I was playing with.
Is there a trick to getting SPM happy with pointing to an active branch as opposed to a specific commit or tag? Right now, it just seems that it doesn’t like being pointed at active branches that see daily development.
This may be fixed in Xcode 14b1, according to this note:
Remote packages are updated during package resolution when using xcodebuild, even if -onlyUsePackageVersionsFromResolvedFile is being passed (the default on Xcode Cloud). This resolves an issue where the package resolved file references commits that are newer than existing local working copies. (82163698) (FB9539493)
It's phrased a bit oddly, so it may not cover this case exactly, but you might want to give it a try. If it doesn't work open another Feedback for Xcode 14 and perhaps we'll see it fixed by the time 14 ships.
I'll probably have to write up some feedback on this issue. I've been testing out Xcode 14 this morning, and don't see any real difference. In today's results, if I try using the command:
…the output finishes up saying "Resolved source packages:" followed by a list of the packages.
I tried it again, this time adding the -disableAutomaticPackageResolution option, and it seemed promising, as the output then added several "Updating from…" lines for each package. After it completed with a message that the packages had been resolved, I had no changes in the downloaded packages - still stuck at the older commits on my develop branch.
Trying from within Xcode 14, I used File > Packages > Reset Package Caches, and the output there indicated that even though I asked for a reset, I was still getting cached versions (see screenshot below). Note the (cached) at the end of each Fetching from… line. Xcode/SPM seems intent on only pulling from these cached locations, unless I manually delete them from the file system.
Yeah, unfortunately it doesn't seem like Xcode's fundamental SPM integration has changed at all in Xcode 14, so all of the existing 13 bugs are still there, despite the few new options they added. I've added an alias to delete the SPM cache on disk, in addition to my existing alias to delete DerivedData, to try and reset state for these issues, but that slows things down even more.
I've added an alias to delete the SPM cache on disk, in addition to my existing alias to delete DerivedData, to try and reset state for these issues, but that slows things down even more.
Yup. I had a similar alias setup for when our team was using Carthage, so I'll just have to add an SPM version as well. Which is a shame, as we have some pretty large dependencies that take a while to download, so if caching worked for the things that haven't changed, that would be great.
@joshbuhler what i noticed when i had this issue was my "clone using" method had changed from SSH to HTTPS. I'm not sure how it happened but after switching it back to SSH i was able to get the latest updates from my packages. i guess this will depend on how your team works with your repos. you can access the "clone using" options via Preferences => Accounts. Worth a try.
I've seen no difference here. No combination of flags to xcodebuild seems to get it to actually update packages, even after deleting the .resolved file.
I also see this problem today on my Xcode 15.3. The way I handled this is the mentioned way in the question by Skwiggs: "specify a different branch, resolve dependerency graph, then revert back to the branch I actually need."