Display package traits

[marcprux]

Package traits (SE-0450) introduced in Swift 6.1 would be a useful thing to list on the package summary, along with their helpful "description" attribute.

For an example of a package that makes extensive use of traits, see https://github.com/sbooth/CSQLite/blob/main/Package.swift

[heckj]

Following up - learning what traits a package offers seems to be down to inspecting Package.swift for the package in question (or dumping it) - so I'll add a +1 to exposing them here on the index as well. Since I'm actively doing some traits research, I'll note that as of August 15th, a public GitHub search showed some 31 independent projects (not forks) that expose traits, a number of which are definitely included in this index (I didn't check all 31).

[daveverwer]

Do you have any examples that include interesting traits? Thanks!

[heckj]

Of the set I reviewed, I thought GateEngine was the most interesting use, but a number of server-side packages offer it as well: https://swiftpackageindex.com/valkey-io/valkey-swift, https://swiftpackageindex.com/swift-otel/swift-otel, and swift-server/swift-aws-lambda-runtime.

The in-process-of-building https://swiftpackageindex.com/swiftlang/swift-subprocess was also interesting, akin to GateEngine, in that it overlaid some platform specific choices with the traits. It uses it to allow a consumer to choose if they're taking on a dependency to Foundation or not. Gateengine offers a trait that configures itself to compile through to WASM, a SIMD enablement that you can disable (although I'm not sure why you would), and a distribution mode that disables some logging and adds from optimizations for running "live". The API being disabled is somewhat against the intent from what I read of the evolution proposal for traits, but arguably still useful in GateEngine's case.

In general, most (public) packages that offer traits that I've found are using a set of default traits, including them so you can disable - if you want to - which takes you down to just a core set of API. My take on the heart of the benefit of this API is a use case that I haven't yet seen in the wild - enabling additional API, which may come with additional dependencies - that extends the core API surface of a package. In the server space, it should be a natural fit to offer a package core package that also wants to offer some specific extensions - akin to plugins - that you can enable if you want that functionality. That looks exactly like what https://swiftpackageindex.com/swift-otel/swift-otel is offering, with two traits - one to report over HTTP, another using gRPC - with both traits currently enabled by default. I expect down the road we'll see that pattern, but maybe not all the extended options enabled by default.

An interesting complication (current issue) is that docc builds (through the plugin, at least) only build with default traits - so packages that offer traits that aren't default don't get symbols generated when you're creating documentation (ref: swiftlang/swift-docc-plugin#108).