1

My package has a target named MessagePack. I am writing benchmarks to compare my package with other packages, so I need to add those other packages as dependencies of my package.

One of those dependencies also has a target named MessagePack. To avoid the naming conflict, I am attempting to use the moduleAliases feature to rename the dependency’s MessagePack target to FlightSchoolMessagePack:

let flightSchoolMessagePackDependency: PackageDescription.Package.Dependency =
   .package(url: "https://github.com/Flight-School/MessagePack.git", from: "1.2.4")
flightSchoolMessagePackDependency.moduleAliases = ["MessagePack": "FlightSchoolMessagePack"]

let package = Package(
   …
   dependencies: [
      flightSchoolMessagePackDependency,
   …
)

However, the Swift package manager still complains:

multiple targets named 'MessagePack' in: 'messagepack', 'msgpack-swift'; consider using the moduleAliases parameter in manifest to provide unique names

Am I misunderstanding something or is this a bug in SwiftPM?

1 Like
2

CC @tomerd who recently sent a related pull request.

3

CC @elsh who implemented the moduleAliases feature.

4

The package manager error goes away if I add a target dependency on a product with the module alias. But now I get the following build error:

Build service could not create build operation: unable to load transferred PIF: PIFLoader: GUID 'PRODUCTREF-PACKAGE-PRODUCT:MessagePack--1CE3093E568ECCB1-dynamic' has already been registered

5
  • The build error is specific to the Xcode build system. I reported the bug in FB13180164.
  • I reported the package manager issue here.
1 Like
6

Hmm I also found that the moduleAliases feature is flaky. I reported the issue here.

1 Like
7

The moduleAliases is meant to be used as a property of a product dependency, not a package dependency. It unfortunately had to be declared public in Package.Dependency at the time it was added due to the need for intra-module visibility, which was before a new access level package was introduced (swift 5.9) that allows the visibility needed (between modules but not to an external client). There are other properties such as .targetItem(name:...) that were made public for the same reason. Once modified with the new access level package, they should be hidden from users.

2 Likes