Logging isn't available on non-Darwin platforms

[itingliu]

There are several places where we log with os.Logger. However the os module is only available on Darwin platforms. We should figure out the story for logging.

[Frizlab]

I long for the day swift-log and os.Logger will be actually unified!

For now I have written a log handler for swift-log to log using os.Logger (or os_log if the OS is not recent enough).

This solution is not great for the well-known reasons:

• No direct support for privacy arguments (I worked around this by only logging static strings and using a rule saying only metadata keys w/ prefix “pub.” are public);
• No support for log location (worked around by adding a custom metadata w/ the log location);
• No support for the optimized arguments handling (I don’t have a workaround for this one).

My next intended step is to write a macro (#log) that will basically expand to

#if canImport(os)
os.Logger(...)
#endif
swiftLogLogger.log(...)

The design solution I have is to only allow logging StaticStrings and have all other info being passed as structured metadata, but that might be overkill.
The privacy info could probably be passed directly in the macro call.
AFAICT all of the issues would be solved.

Having first-class support from Apple for a unified solution would be much better indeed.

[itingliu]

This solution is not great for the well-known reasons:

• No direct support for privacy arguments (I worked around this by only logging static strings and using a rule saying only metadata keys w/ prefix “pub.” are public);
• No support for log location (worked around by adding a custom metadata w/ the log location);
• No support for the optimized arguments handling (I don’t have a workaround for this one).

Yup, using swift-log was indeed the first thing we thought of, but didn't because of these points that you pointed out. On Darwin, persisted logs are valuable for investigating bugs. I'm not familiar with how developers in other platforms would want to use the logs from swift-foundation or in general though; it'd be nice to get some feedback in this area.

[fumoboy007]

Yup, using swift-log was indeed the first thing we thought of, but didn't because of these points that you pointed out.

Perhaps some swift-log changes need to be proposed to better accommodate OSLog? Fundamentally, swift-log should be the sole logging API and OSLog should just be a logging implementation.

It’s a big headache to support two logging APIs. For example, in my swift-retry cross-platform package, I needed to duplicate a bunch of methods: one set of methods for Apple platforms that have OSLog and another set for non-Apple platforms that use swift-log.

The earlier we propose changes to swift-log, the better. The package is still in the Sandbox maturity level, so it should be easier to make changes compared to later maturity levels.

[Lukasa]

We'd love to make swift-log more compatible with oslog, but currently it's not practical to make oslog fit better with the current API requirements it imposes. In particular oslog strongly benefits from having static log format strings, which are incompatible with the structured log metadata spelling that swift-log uses.

A macro-based spelling that matches the two together can work, but only by hitting the lowest common denominator of the two APIs. Generally, that means not using swift-log as the abstraction, but aiming at oslog as the abstraction instead, probably with macros to reduce the duplication. Macros would be necessary to get the best of oslog.

[FranzBusch]

The package is still in the Sandbox maturity level, so it should be easier to make changes compared to later maturity levels.

Just a small clarification the package is Graduated and not in Sandbox. You can find the up-to-date list here.

Another approach is to use the pitched package traits if they get accepted. This would allow to conditionally depend on swift-log on non-Darwin platforms.