During a quick search on GitHub, I found this. It looks like a few repositories are already using it, but I’d rather deal with breakages now than after the signal is marked as stable. Would like to have some thoughts from maintainers.

This should be fine since the signal is experimental.

Discovered this PR after finding a breaking change in our logging handler when updating to 1.35.0. For our use case, we do not want to depend on the SDK, which is now required after this change. I suspect other folks implementing custom logging handlers are in the same position.

Discovered this PR after finding a breaking change in our logging handler when updating to 1.35.0. For our use case, we do not want to depend on the SDK, which is now required after this change. I suspect other folks implementing custom logging handlers are in the same position.

If you are using another sdk implementation, you can just reimplement the thing there?

I also have a custom exporter for structlog. It was using this std_to_otel function. I understand your suggestion is to copy the function into my own implementation - yes?

Given the small footprint, we copied std_to_otel into our implementation

I also have a custom exporter for structlog. It was using this std_to_otel function. I understand your suggestion is to copy the function into my own implementation - yes?

Well, this is a different use case and possibly the reason why this was in the api 😅

Given the small footprint, we copied std_to_otel into our implementation

Also ended up copying the function into my own code