I would expect to see listed within the my package's Package.swift
file all dependencies to other pacakges I add using Xcode but it is not the case.
Is there an extra step I am missing to have my Package.swift
file synched?
Thanks!
I would expect to see listed within the my package's Package.swift
file all dependencies to other pacakges I add using Xcode but it is not the case.
Is there an extra step I am missing to have my Package.swift
file synched?
Thanks!
They arenât the same thing.
You can have either a Swift package or an Xcode project as a topâlevel entity, but not both. (However, you can add things as dependencies of a Swift package, and have an Xcode project depend on that local package.)
I think @Victor_Guerra is referring to Xcodeâs integration with SPM. The fact that it offers no tooling around working with the package file, much less automatically adding dependencies as youâd expect, is just another point that shows the SPM support perfunctory. Itâs unfortunate that after so long, this is all we get for a year.
I know that.
However, if you open a package in Xcode, âAdd Package Dependency...â is greyed out, because Xcode cannot do that at all. It can only do that for Xcode projects.
(Asking the Xcode developers to enable it for packages too and have it do something usefulâas you sayâwould make perfect sense.)
However, Victor wrote this:
That implies he successfully clicked on âAdd Package Dependency...â and it did something.
From that, I suspect he is mistaken and isnât actually adding the dependencies to a package. He must have something else open (too?) that he is adding dependencies to, and that is why they are not appearing in the manifestâthey are actually dependencies of something else.
I think he just expected the obvious behavior: that projects using SPM through Xcode maintain a package file. Itâs unfortunate that Xcode just maintains it in parallel. Additionally, not properly supporting packages when it defaults to opening them in a directory with project and workspace files, is additionally confusing.
But thatâs the thing, even if they live in the same directory, the package and the Xcode project are two separate things. If you have a package and a project within an Xcode workspace, then the package might be a dependency of the Xcode project, but the two should not be seen as equal to each other:
You can have a dependency of the Xcode project that is not a dependency of the package. For this, you enter it in Xcodeâs user interface, because it tracks such dependencies in its own opaque way in hidden in an .xcodeproj
bundle like it does everything else about the project (a practice I am not defending).
You can have a dependency of the package that is not a dependency of the Xcode project. For this, you enter it in the package manifest. (But if the package is itself a dependency of the project, the project will inherit such dependencies transitively.)
Xcode should not synchronize the two dependency lists, because they are different things.
I just experimented, and if you have two projects and a package in the same workspace, you can click âAdd Package Dependency...â. The first thing it does is ask which thing to add the dependency to. It gives you the two projects as options, but not the package since it doesnât support doing that (yet?).
Presumably it skips this step when there is only one viable thing to attach the dependency to. If you instead have a workspace with one project and two packages, it doesnât ask and instead selects the only thing possibleâthe projectâwithout showing the panel. While that makes a certain sort of sense, I can see how it obscures what you are actually asking it to do. It feels more like you would be adding it to the whole workspace even though that is not the case.
That illusion would be much compounded if the workspace consisted of exactly one package and one project that were being merely used as two ways of vending moreâorâless the same thing. Despite the actual presence of three separate entitiesâa workspace, a project and a packageâyou could feel like you are only working with only one entity, and you might expect all ways of looking at it to have the same information and the same dependencies. But that does not reflect the actual design, which allows for any number of interrelated components.
Additionally, not properly supporting packages when it defaults to opening them in a directory with project and workspace files, is additionally confusing.
There is no project involved. When you doubleâclick Package.swift
, it creates a transient workspace containing only the package. That is why the interface wonât let you do projectârelated things to it like add configurations, localizations or build settings. There is no project to store them in.