Standards for using swift-log across multiple different packages about swift-log HOT 1 OPEN

When one is using swift-log across multiple different packages, should one use the same Logger instance across these packages or is it acceptable to use different instances?

Ultimately it is up to you and the needs of your system/application.

It may help to think about where/how you'd like to change log levels; which implies where loggers may need to be created for a subsystem. Note that creating a "new" logger with a changed log level is simply: var l = baseLogger; l.logLevel = .warn. So some people use it like this and pass a "single" base logger around, modifying it as they go. The source parameter can be used to identify "what module" has logged then as well (though we need more work with that parameter's default value).

Normally it is either recommended to either:

• go all-in passing the logger to all types and functions which need it
  • this is the currently most widely adopted pattern I'd say
  • func hello(param: Param, other: Other, logger: Logger)
• OR go all-in on everyone getting their logger instance ad hoc.
  • For the latter solution we currently do not have a great log handler backend which would allow changing configuration on the fly, but that's an alternative to consider.

Server side frameworks nowadays opt for the explicit logger passing. With the baggage context work there may be new patterns emerging, i.e. "context objects", but that's not entirely baked yet. The primary use of those is for distributed tracing.

APIs are likely to take the shape of: func hello(param: Param, other: Other, context: ...Context) (and context has context.logger which also uses the baggage value -- which enables marrying distributed tracing and logging).

from swift-log.