So I am working on two packages in tandem, where Package A depends on Package B.
Package A -> Package B
Each package is in a separate git repository, and I would like to avoid having to push changes from Package B to remote every time I make a change just to be able to use it with Package A.
Using the documentation here, I have put Package B in edit mode like so:
$ cd /path/to/package_a/checkout/location
$ swift package edit PackageB --path /path/to/package_b/checkout/location
Based on my understanding, this should basically tell SPM to reference the local checkout of the package, at the specified --path , rather than managing its own checkout.
But the thing is, if I open package A in XCode:
open /path/to/package_a/checkout/location/Package.swift
And I go to "show source" on Package B, it's showing me the checkout in the derived data folder.
So it seems like XCode is not observing the edit mode configuration provided by SPM? Or else how do I achieve having XCode point to a local checkout of a package rather than the default behavior?
Yes Xcode is a special case, which involves dragging the projects into a shared workspace. I wrote a blog explaining how to do it. If you want a more CLI-like experience then maybe VSCode is a better option
Ah ok, good to know. It's a bit disappointing: imo this is a regression, since generate-xcodeproj was able to handle edit mode gracefully within XCode.
Both commands (edit, generate-xcodeproj) are headed toward eventual removal. The intent is for SwiftPM handle local overrides essentially as Xcode does today.
This is kind of a bummer, as it makes SPM totally dependent on XCode. I can understand removing generate-xcodeproj as opening the package directly in XCode is a sensible solution, but edit mode is essentially a requirement for working on complex Swift projects.
I asked the main team the exact same question when I first caught wind of it. They do not intend to remove edit until their replacement feature is in place. From what I understand, basically the plan is for a local instance of the same identity to automatically override whatever is in the dependency graph (much like Xcode). (Edit: That was a horrible description; see later comments instead.) What SwiftPM does right now under the hood is a fragile mess, because it has to record which mode it is in for what, and trips as soon as the user adjusts the file system behind its back.
Ok interesting. I am not sure exactly what the intended design is, but based on what you're describing imo it would be much better to handle this explicitly. If SwiftPM is just magically deciding which packages to override with a local copy, I can imagine this being difficult to debug and leading to frustration when it doesn't work.
Also how does it decide where the search paths are? Does it depend on having the packages in the same parent directory? Or does it depend on where you run the swift build command from?
Imo it makes things much more repeatable and is better aligned with the unix philosophy to have explicit commands for this, and edit mode is already a satisfactory solution. If you wanted to have automatic management, this could be build as an additional utility function on top of edit mode.