Traits apply to packages instead of products

[davedelong]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps with either of command-line SwiftPM commands, swift build, swift test, swift package etc.

Description

As reported here: https://forums.swift.org/t/cross-import-overlay-status/74090/9

It is a design flaw that traits apply to packages instead of single products. A package can provide many products, and each product may have their own unique set of traits that it wants to expose, and a client may not want to apply all traits to every product.

For example, a package that exposes both a "logic" product and a "UI" product that provides SwiftUI views around the types in the logic product could easily have traits that only apply to one or the other. Perhaps a Debug trait might apply to both, but an ProvideUIKitBindings might only apply to the UI product.

Traits should be defined on the product, not the package.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

Swift Package Manager version/commit hash

Swift Package Manager - Swift 6.0.3

Swift & OS version (output of swift --version ; uname -a)

swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.9 clang-1600.0.30.1)

Darwin Localhost 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020 arm64

[MaxDesiatov]

cc @FranzBusch

[FranzBusch]

Thanks for filing this @davedelong

We deliberately choose package level here since products are often just an underlying library or executable target. In practice, those underlying targets often have dependencies on other targets in the same package. Often those targets also need to be aware of which trait is active. That's why we choose to define traits on package level so that all targets get the active trait information passed to them via defines. Additionally, we felt that developers can use naming patterns to communicate if a trait only applies to a certain product.

In the end, I wouldn't call this a design flaw but rather a choice that we made reflecting the reality of how many packages are setup. I think it would be worth exploring product specific traits in a future proposal though.

[dschaefer2]

This is an interesting issue. I think this goes all the way back to "What is a package"? I think we've ended up in a spot where it's a lot easier to combine products in a Package than to have cohesive Packages where it probably shouldn't make sense to have products have different traits. I think that's the intent of the package visibility where Packages are actually semantic things in the language, not just a build and distribution mechanism.

Some of this comes back to monorepos and our restriction that each repo can only have one Package.swift. We do have Issues where we should look at how to relax that restriction and make it a lot easier for people to make multiple Packages in their git repos.

At any rate, I'd like to hear more about the use cases and make sure we take them into account as we try and support monorepos.