You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If AddSource=true, the source field in the log is a relative file name, relative to the current working directory. That does work ok when this handler is used in code being run from a go project, as the go source files are typically relative to the project's root folder, and that's typically also going to be the CWD when the project is run.
But if the executable is run from a different location (like if it is packaged in a docker container), when the working directory is going to be unrelated to the source file location. You end up with log entries like:
What would be ideal is to always calculate the relative path against the root of the go module that particular source file originally came from, but I'm not sure that's possible.
I don't have a suggestion for an alternative yet. I'll think about it. I think other projects just show the filename with no path.
The text was updated successfully, but these errors were encountered:
ansel1
added a commit
to ansel1/console-slog
that referenced
this issue
Jan 17, 2025
Only make the source file path relative to the current working directly *if* the source file is a child path of the current working directory.
Typically, the source file path will only be a child of the CWD when the code is being run from its own project folder. But if the executable moved somewhere else first, or packaged in a container, or compiled with the -trimpath option, then this relative path logic doesn't work.
If the file path isn't related to the CWT, then trim to just one path element above the file name, which is typically the go package name, e.g. "io/reader.go"
Address phsym#16
Only make the source file path relative to the current working directly if the source file is a child path of the current working directory.
Typically, the source file path will only be a child of the CWD when the code is being run from its own project folder. But if the executable moved somewhere else first, or packaged in a container, or compiled with the -trimpath option, then this relative path logic doesn't work.
If the file path isn't related to the CWT, then trim to just one path element above the file name, which is typically the go package name, e.g. "io/reader.go"
Addresses phsym#16
If AddSource=true, the source field in the log is a relative file name, relative to the current working directory. That does work ok when this handler is used in code being run from a go project, as the go source files are typically relative to the project's root folder, and that's typically also going to be the CWD when the project is run.
But if the executable is run from a different location (like if it is packaged in a docker container), when the working directory is going to be unrelated to the source file location. You end up with log entries like:
What would be ideal is to always calculate the relative path against the root of the go module that particular source file originally came from, but I'm not sure that's possible.
I don't have a suggestion for an alternative yet. I'll think about it. I think other projects just show the filename with no path.
The text was updated successfully, but these errors were encountered: