-
Notifications
You must be signed in to change notification settings - Fork 294
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
The default "source" module determined by Logger/LogHandler is usually wrong #145
Comments
Damn, feeling silly this slipped through when we were talking about Will ponder some more soon and try to see if a "real" solution is anywhere near in sight... |
Marked as 1.3.1 but I don't think we'll actually solve it there, just a reminder for myself to poke around some more. |
Is this easy to fix now that we have |
Do you want to send in a PR @porglezomp ? That'd help a lot :-) |
It looks like this is actually already fixed in Swift 5.3+, with PR #187. |
Excellent, thanks for the info and sorry I missed the reply here way back then :) |
Expected behavior
Given this package layout:
If I perform
someLogger.info("hello")
inModuleA/Subdir1/Impl.swift
andsomeLogger.info("world")
inModuleB/Subdir1/Impl.swift
, I expect that thesource
parameters which reach the underlyingLogHandler
will be, respectively,ModuleA
andModuleB
.Actual behavior
In practice, the
source
parameter will beSubdir1
in both calls.SwiftLog version/commit hash
SwiftLog 1.3.0
Swift & OS version (output of
swift --version && uname -a
)Further information
This is the natural result of using what is essentially
basename(dirname(#file))
as the default forsource
inLogger.currentModule(filePath:)
(swift-log/Sources/Logging/Logging.swift
Line 762 in 57c6bd0
Logger.log(level:_:metadata:source:file:function:line:)
(swift-log/Sources/Logging/Logging.swift
Line 75 in 57c6bd0
Logger
'slog()
method, it is difficult to override it via, for example, a project's choice ofLogHandler
, with the result that this newsource
parameter (otherwise a very useful input) must be ignored in favor of continuing to use such problematic solutions as parsing#file
or#filePath
(the irony that this behavior is also the cause of this very issue is not lost on me!).The text was updated successfully, but these errors were encountered: