[Proposal] SDT-0002: move ServiceContext from SSC to SDT

Server Development
1

Hi all,

The proposal SDT-0002: move ServiceContext from SSC to SDT for swift-distributed-tracing is now up and In Review.

The review period will run until September 22nd — please feel free to post your feedback as a reply to this thread.

Thanks!

2 Likes
2

+1 from me

ServiceContext is rarely used outside distributed tracing and removing the extra package makes sense here.

1 Like
3

Can the proposal be amended to discuss the package dependency situation? Right now SDT depends on SSC. Will that flip? Is it possible that this flip breaks any adopters?

4

@Honza_Dvorsky Dependencies flip indeed. I think I've covered all the cases in the proposal. One case will break is when someone relied on transitive dependency of ServiceContextModule being available through swift-distributed-tracing.

5

I guess even this is a break?

  • Upgrading only one of the two packages, so an old swift-service-context and a new swift-distributed-tracing resolve together, fails to build: ambiguous use of 'ServiceContext'.

Could you maybe put all the possible breaks into an explicit section? It's worth discussing how much this change is truly SemVer minor vs SemVer major.

6

I've update the "API Stability" section with "Breaking changes" subsection:

  • A file that writes import ServiceContextModule without its own package declaring a dependency on swift-service-context, relying only on the module being present transitively through swift-distributed-tracing, loses the module and gets error: no such module 'ServiceContextModule'. The fix is to declare the dependency explicitly.
  • Upgrading only one of the two packages, so an old swift-service-context and a new swift-distributed-tracing resolve together in one build, fails to build with ambiguous use of 'ServiceContext'. The fix is both packages must be upgraded together.
7

After more discussion, I think this is a reasonable change.

To address the first breakage, can we bump the ask for the explicit dependencies error flag to become the default? If we hold that packages are free to move components around this way and some of it might break adopters, the tools should help adopters avoid this breakage by adding any missing explicit dependencies. @FranzBusch Are you aware of an issue we can bump here?

Also, can we add an issue in both SDT and SSC that contains the exact error message folks will see if they hit either of these scenarios, so that they can quickly figure out what happened and how to unblock themselves? I recommend also pinning that issue to the top for e.g. 6-12 months.

Thanks @kukushechkin, I do look forward to the dependency graph being simplified a bit :slight_smile:

1 Like
8

:+1: We discussed this in depth and I'm also supportive, it'll be a good cleanup of the package organization. I think the future lies in using more task locals directly as the future directions outline, so this nudges us in the right direction (rather than making it a new "the one and only context" package).

2 Likes
9

Hi all,

The review period for SDT-0002: move ServiceContext from SSC to SDT is now over. The proposal is now accepted and is Ready for Implementation.

When a new version of either SDT or SSC is tagged, there will be an Issue created in the corresponding repo explaining how to fix compilation errors related to the breaking changes discussed above.

Thank you for the discussion, let's simplify the dependency graph a bit!

2 Likes
10

We are using ServiceContext outside and unrelated to distributed tracing. Please reconsider this change. I don't follow the motivation but I'm commenting in more detail below:

Most adopters reach ServiceContextModule only through Tracing, not as a direct dependency, so the
two-package split mostly adds release latency for a type whose main consumer is one package.

This is not convincing. Working around deficiencies in the package manager -- which are being addressed -- by compromising the layering does not seem right to me.

ServiceContext also reads as Swift Server specific.

Renaming the type to a less server-y name would be okay with me.

In practice it carries any ambient, propagated state,
not just service-to-service request state, and the name has stopped people from adopting
swift-distributed-tracing outside server applications.

How and why has it stopped people adopting swift-distributed-tracing outside of server applications? Are people really discarding useful code because the package/type name contains the word 'service'?

1 Like
11

For anyone using ServiceContext outside of tracing context, there are three options:

  1. Pin the last release before the move: .package(url: "https://github.com/apple/swift-service-context.git", exact: "1.3.0").
  2. Fork or reimplement it. ServiceContext essentially is a type-safe bag of values stored in a task-local, so keeping your own copy is cheap if you'd rather not depend on either package.
  3. Accept the SDT dependency.

As mentioned above, we'll also open an issue with migration details when the new versions are tagged.

1 Like