1

In quite a few of my projects as well as in our company we organized our code into several packages. Each package has its own repository. Some packages are use by several other packages, for example a packages with reusable helpers.

What we usually do when we need to work on the package, as well as the main project. we would add the package that needs editing through the Project -> Package Dependencies tab in Xcode as a local package. By doing so, the package is then linked as a local package in the navigator.

That worked perfect and allowed us to easily edit the package, each other package that depends on it, would also use the local package.

However, since the latest Xcode 15.0 betas, we start getting warnings, that the local package has the same identity as the non local package. Which of course it has, it is the same package. It says that in a future version of SwiftPM, this will cause an error.

However, this would cause a lot of issues, as this would mean, in order to work with a package locally, we would have to change every dependency in every Package.swift that uses this package to the local path. Only to change it back after we're done working on one single package.

I'm wondering if this is really intended that way, or if there is some setting or flag that can be set to not have those issues and keep developing locally.

I still think that adding a local dependency through Xcode should supersede all non local imports for developing purposes.

Here is one of those warnings I'm currently getting:

'store' dependency on 'https://github.com/marcoboerner/OpenHelper' conflicts with dependency on '/Users/marcoboerner/Development/OpenSource/OpenHelper' which has the same identity 'openhelper'. this will be escalated to an error in future versions of SwiftPM.
2 Likes
2

This seems like a bug. If you could file a bug through Feedback Assistant and share a reproducer of some sort that would be appreciated.

1 Like
3

Thanks for the advice, I've submitted my feedback with the ID: FB12788952

4

I got a reply from Apple regarding this issue. It seems this new error is expected behavior and will break this common workflow in the future.

From what I understand, the correct workflow for developing packages locally is to drag the package that needs local editing from Finder into Xcode and then edit from there. Once editing is done the reference can be removed again. It tested it and it does work. I'm not exactly sure what the reason is behind this change.

Here are the steps I provided Apple to reproduce the issue:

  • Create a new Xcode Project (iOS App for example)

  • Create a new Package (Library Multiplatform) inside the project, adding it to the project/group

  • Add a dependency to this project, for example, GitHub - apple/swift-collections: Commonly used data structures for Swift

  • Clone the same repository into a different folder, not within the project

  • Add the package as a local package in Xcode > Project > Package Dependencies (select any of its modules, but can be deleted from the targets frameworks

  • The package is now shown as a local package, which can be edited as expected.

  • However, at the same time the following warning is shown: ...

Here is what Apple answered:

Thank you for filing this feedback report. We reviewed your report and determined the behavior you experienced is currently functioning as intended.

  • Add the package as a local package in Xcode > Project > Package Dependencies (select any of its modules, but can be deleted from the targets frameworks

This adds a local dependency to the Xcode project which cannot reliably override another dependency, hence the warning.

Only root packages can override; those can be added to Xcode (e.g. dragging the collections checkout into the project).

5

I don't believe this is a change in how root vs. local packages are being handled, but a change in the "Add Package Dependency" workflow.

It used to be the case that adding a dependency through that workflow would add the package in question as a root package, but these days it adds it as a local one (the equivalent of .package(path:)). Prior to this change, I don't believe Xcode supported local dependencies in projects, only in other packages.

The documentation still only describes the root package workflow btw, but calls it "local package" which could become confusing now that Xcode also supports "real" local packages.

1 Like
6

We adopted SwiftPM pretty early, I think we just got used (and never questioned) our workflow so far. I haven't even seen the mentioned part of the documentation until now. Thanks for pointing this out! But I agree, would be nice if both workflows would be described and clearly differentiated. But it does make sense now, considering that remote, root, and local packages are all supported.