StdoutLogHandler should be public about swift-log HOT 20 CLOSED

Maybe we should ship StdoutLogHandler and StderrLogHandler.

yeah, could just have a LogStdioHandler that takes a FILE * or a file descriptor... And make the default either LogStdioHandler(stdout) or LogStdioHandler(stderr)

from swift-log.

I'd be okay with that, but we should name it StderrHandler and make it log to stderr :). It's no good logging to stdout but I forgot to fix it...

from swift-log.

Maybe we should ship StdoutLogHandler and StderrLogHandler.

from swift-log.

👍 on shipping both, makes sense and does not widen the scope of the lib too much; this still counts as "bare minimum" etc. I think.

Btw. re 12-factor apps... the rules are ok-ish... but in reality some of the hints are very weird (the configuration one + security springs to mind), so it's good as general inspiration but I don't think one should follow those when designing APIs like a bible of app design :-)

from swift-log.

Thanks for all the feedback here. Just wanted to say I can make StdoutLogHandler public via a PR, but the other proposals seems a bit out of scope for me!

from swift-log.

fixed by #61

from swift-log.

Hi Allen, really cool that you're looking to adopt the API, and thanks for chiming in!

As you notice, it is early days here, and not many implementations of this API exist yet. Our hope is that soon someone would implement a much better standard out logger that would support formatting etc. It is true though that the built in one provides a nice out of the box default...

I think it sounds good on making it public, it seems to have been intended to be so; and it is accessible in any case for using it via "not configuring anything"; We could also address the docs comment on it while we're at it (perhaps something more clear that it's "boring" :-)), mentioning that it is intended to be a bare-minimum implementation and proper log handlers with formatting are expected to be external modules?

We'll see what @weissi and @tomerd think, but sounds to me like a plan to have it publicly constructable, since we "ship it" and it is "to be used by users" anyway.

from swift-log.

Why stderr? https://12factor.net/logs

from swift-log.

Why stderr? https://12factor.net/logs

Command line apps are pretty unusable if you log to stdout. Imagine you do

cat myImage.HEIC | my-swift-heic-to-jpg-transcoder > myImage.jpg

that'd break horribly if you log to stdout. Obviously we could say in that case people need to install their own log handler...

from swift-log.

I dug around a bit.

kubectl logs aggregates stdout and stderr.
Cloud Foundry does the same - https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html
Mesos likewise - http://mesos.apache.org/documentation/latest/logging/#Containers

Maybe the 12-factor requirement of stdout isn't realistic in practice..

from swift-log.

I dug around a bit.

kubectl logs aggregates stdout and stderr.
Cloud Foundry does the same - https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html
Mesos likewise - http://mesos.apache.org/documentation/latest/logging/#Containers

Maybe the 12-factor requirement of stdout isn't realistic in practice..

Yeah, I find it a bit odd that they require stdout... Anyway, I guess the best argument for leaving it stdout is that we shipped 1.0.0 with it and you could say it's a breaking change...

from swift-log.

Yeah. I do think we should make StdoutLogHandler public - for the 12-factor style of app it's useful.

from swift-log.

@ianpartridge 2>&1 would make a stderr-logging thing 12-factor again, so I don't think whatever 12-factor came up with should be the deciding argument here.

All real-world deployments will definitely have to take anything on stderr too because that's where Swift crashes get written too.

from swift-log.

@allenhumphreys I think we'd welcome that first PR :)

from swift-log.

@ianpartridge I went to commit and was following CONTRIBUTING.md's advice to use dev/git.commit.template as the commit template, but found that seems to be a holdover from where this project started (SwiftNIO?).

As part of my update I could:

1. Add the template so the instructions are accurate
2. Update the instructions so they don't reference the template

from swift-log.

Ah, thanks for letting us know. I think we should fix that in a separate PR - @weissi?

from swift-log.

I think we should fix that in a separate PR - @weissi?

Yes please :)

from swift-log.

I think we should fix that in a separate PR -

#62

from swift-log.

Seems we missed to close this issue; Seems solved ( by #61 and see also https://github.com/apple/swift-log/blob/master/Sources/Logging/Logging.swift#L539-L549 )

from swift-log.

Assigned to 1.0.1 milestone, and closed the 1.0.0 milestone as well since it seems to have been still open even tho we tagged 1.0.0.

from swift-log.