Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standards for using swift-log across multiple different packages #155

Open
crspybits opened this issue Aug 29, 2020 · 1 comment
Open

Standards for using swift-log across multiple different packages #155

crspybits opened this issue Aug 29, 2020 · 1 comment
Labels
kind/support Adopter support requests.

Comments

@crspybits
Copy link
Contributor

I have a question on standards of usage. 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? If using the same instance, is there a standard means to propagate that instance across packages? (e.g., some kind of dependency injection?).

Thanks,
Chris.

@ktoso ktoso added the kind/support Adopter support requests. label Aug 31, 2020
@ktoso
Copy link
Member

ktoso commented Aug 31, 2020

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/support Adopter support requests.
Projects
None yet
Development

No branches or pull requests

2 participants