feat: logging filter #1336
Merged
feat: logging filter #1336
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zimbatm
reviewed
Oct 11, 2024
internal/cmd/log.go
Outdated
| shouldLog := true | ||
| filter, ok := env["DIRENV_LOG_FILTER"] | ||
| if ok { | ||
| filterRegEx, err := regexp.Compile(filter) |
There was a problem hiding this comment.
If you want to use it on both sides, then this has to use the same regexp engine as bash. I believe it's PCRE.
Alternatively, it would be acceptable to introduce a direnv log command to invoke on the stdlib side.
There was a problem hiding this comment.
I added the direnv log command, and made stdlib call it
added 2 commits
October 21, 2024 20:59
zimbatm
reviewed
Oct 22, 2024
stdlib.sh
Outdated
Comment on lines
136
to
143
| local msg=$* color_normal='' | ||
| if [[ -t 2 ]]; then | ||
| color_normal="\e[m" | ||
| fi | ||
| local -r direnv_msg=$(direnv log "$msg" 2>&1) | ||
| if [[ -n "$direnv_msg" ]]; then | ||
| printf "${color_normal}%s\n" "${direnv_msg}" >&2 | ||
| fi |
There was a problem hiding this comment.
Could you move the rest of the logic so that this function can be reduced to:
log_status() {
direnv log -status -- "$*"
}
And port the log_error() too, and then finally, both sides will be fully in sync.
There was a problem hiding this comment.
I've made the changes; the only issue was the shade of red used, as it was different in stdlib.sh ("\e[38;5;1m") as compared to the colour in go (\033[31m).
I used the colour in go.
We want to move the config to the config file where possible
|
thanks, I went a bit further and moved the config to the config file, but also broke something in the process. I might push that out as a follow-up PR instead, unless you also want to help out with this. |
|
Sure, I don't mind taking a look |
|
I think I fixed the issue: it wasn't applying the default format if there was no TOML config file, yay for tests! |
This reverts commit fa89e53. Logs are already sent to stderr
|
Are we good to merge? |
|
yup, thank you |
jparise
added a commit
to jparise/direnv
that referenced
this pull request
Dec 26, 2024
These new configuration fields were recently introduced in direnv#1336 and will be included in the next minor version (presumably v2.36.0). This makes it clearer that these options aren't available in older released versions. The annotation format is the same as what is used for 'load_dotenv'.
zimbatm
pushed a commit
that referenced
this pull request
Mar 25, 2025
These new configuration fields were recently introduced in #1336 and will be included in the next minor version (presumably v2.36.0). This makes it clearer that these options aren't available in older released versions. The annotation format is the same as what is used for 'load_dotenv'.
This was referenced Apr 25, 2025
13 tasks
9999years
added a commit
to 9999years/nixpkgs
that referenced
this pull request
May 9, 2025
`direnv` 2.36.0 [changed how logging worked][1]. As a result, the
`$DIRENV_LOG_FORMAT` variable is no longer set when the `nix-direnv`
`direnvrc` is sourced. Previously, setting `$DIRENV_LOG_FORMAT` to the
empty string was [the recommended solution for disabling all log
output][2]. Therefore, `nix-direnv`'s warnings are completely silenced
when using the latest `direnv`.
`nix-direnv` 3.0.7 fixes this issue.
Warnings being silenced leads to very surprising behavior and output.
We use an `.envrc` that looks like this:
nix_direnv_manual_reload
use flake
`nix_direnv_manual_reload` means that `use flake` is ignored unless a
cache already exists. It's supposed to print a warning making this
clear, which looks like this:
$ direnv allow
direnv: loading ~/my-repo/.envrc
direnv: using flake
direnv: nix-direnv: cache does not exist. use "nix-direnv-reload" to create it
direnv: export ~PATH
However, with the latest `direnv`, it prints this output instead:
$ direnv allow
direnv: loading ~/my-repo/.envrc
direnv: using flake
direnv: export ~PATH
This is very misleading; it prints `using flake` as if it's loading the
Flake, but actually nothing is happening and the Flake is being ignored
entirely!
[1]: direnv/direnv#1336
[2]: direnv/direnv#68 (comment)
FilipTLW
pushed a commit
to FilipTLW/nixpkgs
that referenced
this pull request
May 10, 2025
`direnv` 2.36.0 [changed how logging worked][1]. As a result, the
`$DIRENV_LOG_FORMAT` variable is no longer set when the `nix-direnv`
`direnvrc` is sourced. Previously, setting `$DIRENV_LOG_FORMAT` to the
empty string was [the recommended solution for disabling all log
output][2]. Therefore, `nix-direnv`'s warnings are completely silenced
when using the latest `direnv`.
`nix-direnv` 3.0.7 fixes this issue.
Warnings being silenced leads to very surprising behavior and output.
We use an `.envrc` that looks like this:
nix_direnv_manual_reload
use flake
`nix_direnv_manual_reload` means that `use flake` is ignored unless a
cache already exists. It's supposed to print a warning making this
clear, which looks like this:
$ direnv allow
direnv: loading ~/my-repo/.envrc
direnv: using flake
direnv: nix-direnv: cache does not exist. use "nix-direnv-reload" to create it
direnv: export ~PATH
However, with the latest `direnv`, it prints this output instead:
$ direnv allow
direnv: loading ~/my-repo/.envrc
direnv: using flake
direnv: export ~PATH
This is very misleading; it prints `using flake` as if it's loading the
Flake, but actually nothing is happening and the Flake is being ignored
entirely!
[1]: direnv/direnv#1336
[2]: direnv/direnv#68 (comment)
|
For future readers: if you have output like this and want to only see loading and not all exported env vars which takes lot of real estate this is what workes: [global]
log_filter="^loading" |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allows you to filter the log messages that are outputted.
Should help with this