Traits update #9554
Traits update #9554
Conversation
|
@swift-ci please test |
| When Swift Package Manager builds with a requested trait, it does so across the package dependency tree, propagating that request for traits throughout the dependencies. | ||
| Traits affect all targets being built in the package as well as any dependencies, not just targets within a package. |
There was a problem hiding this comment.
I don't think this one's true as written. Traits live in per-package namespaces. If root package Foo has trait T enabled, and wants trait T enabled in dependency Bar, it has to convert (namespacing explicitly here for illustration purposes) Foo.T to Bar.T explicitly in Package.swift. @FranzBusch, @bripeticca do I understand this correctly?
There was a problem hiding this comment.
I'll let Bri or Franz respond for sure but I believe Max to be correct here. I will comment that Traits are highly misunderstood. We need to be very crisp in the documentation. I'll take a closer look when I get back from my break next week.
There was a problem hiding this comment.
Yeah, that's why I kept this in Draft - I want to make sure this is dead on correct and nailed down.
My confusion came from what you invoke a build with traits, you're giving it a set of strings to represent the traits - if two packages happen to offer traits that use the same name, are both enabled?
There was a problem hiding this comment.
My confusion came from what you invoke a build with traits, you're giving it a set of strings to represent the traits - if two packages happen to offer traits that use the same name, are both enabled?
For two different packages the answer in general is "no" (unless you wire up traits with same names between packages explicitly in Package.swift), but in which package namespace they live depends on which is a root and which is a dependency.
The set of strings represents traits in the top-level (root) package namespace.
Only traits in the root package are enabled by CLI options, the dependency needs them passed down explicitly. If the dependency is transitive, they need to be passed down explicitly multiple times at each dependency level in each Package.swift.
There was a problem hiding this comment.
The key thing I keep coming back to is that traits are a way to specify feature optionality for a given package. We don't support features that span multiple packages. As Max mentioned, a package may request a trait to be enabled in the dependency on that package but that's actually unrelated to the traits in that package. (That said, we should be allowing dependencies and their traits setting to be conditional on a package's traits as well).
There was a problem hiding this comment.
Essentially what @MaxDesiatov mentioned, specifying traits to enable through the CLI will only affect the enabled traits of the root package. There isn't currently a way to specify enabled traits for dependencies through the CLI, but one can configure enabled traits of a dependency in the root package's manifest.
| Swift Package Manager exposes enabled traits as conditional blocks (for example, `#if YourTrait`) that you can use to conditionally enable imports or different compilation paths in code. | ||
|
|
||
| Traits are identified by their names, which are name-spaced within the package that hosts them. | ||
| Trait names are name-spaced within the package that hosts them. <!-- what's this mean, exactly - what does this enable or impact? pending question to Bri --> |
There was a problem hiding this comment.
Covered in the comment above, it means that trait T declared in multiple packages are actually different unrelated traits.
4 participants
Updating the traits documentation to touch on missed pieces and revise to conform a little better to developer content guidelines.
Motivation:
Modifications:
Grammar revisions and added sentences for clarity.