-
Notifications
You must be signed in to change notification settings - Fork 320
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
trusted_config_paths has no effect #3229
Comments
¯\_(ツ)_/¯ it's working for me if I set here's the code which might give you an idea of what it is that is going awry: mise/src/config/config_file/mod.rs Lines 248 to 295 in f246584
|
Ok, that's weird. |
are you actually setting it as an env var? |
Sure, as shown in my # ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects |
Hello @gdlx, I had a similar experience to what you described and spent a couple of hours trying to figure out what was going on. Eventually, I decided to pull the mise repository and debug it. I discovered that my configuration was untrusted because it was “ignored.” Here’s the relevant code snippet: pub fn is_trusted(path: &Path) -> bool {
let canonicalized_path = match path.canonicalize() {
Ok(p) => p,
Err(err) => {
debug!("trust canonicalize: {err}");
return false;
}
};
if is_ignored(canonicalized_path.as_path()) {
return false; // my code returns here
} I believe this happened when mise prompted me with: To fix this, you can remove your target configuration from the “ignore list” by temporarily trusting it: mise trust --all Then, you can “untrust” the configuration by running: mise trust --untrust At this point, the configuration will no longer be in either the “ignore” or “trust” lists, allowing you to test the behavior from scratch: export MISE_TRUSTED_CONFIG_PATHS=~/projects
mise trust --show (or just visit I hope this helps! Let me know if you need further clarification. |
note that this logic changed significantly in the last release, previously it tracked files but now it tracks the directory so you don't need to trust every I did try to make it backwards-compatible where previously tracked individual files will still be trusted |
fwiw this is the intended behavior, otherwise we would prompt all the time and it would never go away |
I agree with you, I just did it (implicitly added to permanent ignore by clicking "No" in the "do you trust" question) and forgot after that, so at the moment I was confused |
Describe the bug
Since upgrading Mise last week, I have issues with config trust.
I have a Mise config file in a Python project:
Config file isn't trusted by default since v2024.11.24 (it's trusted by default when downgrading to v2024.11.23), while global files are still trusted:
The consequence is my kustomize install isn't considered current anymore.
Even if it is installed globally, I could need a different version in my project, so my code checks it's installed with
--current
:Everything works fine when trusting the file directly:
But I don't want to do this because I have multiple projects with the same setup and I don't want to trust every config file. I'd prefer doing it with the
MISE_TRUSTED_CONFIG_PATHS
, globally for all projects on the~/projects
directory or even in each project dir by setting the variable on execution.My problem is thas the setting seems to be completely ignored.
To Reproduce
trusted_config_paths
just seems to be ignored.I tried with setting
MISE_TRUSTED_CONFIG_PATHS
to multiple paths and syntaxes with the same result:~/projects/
~/projects/myproject
~/projects/myproject/
~/projects/myproject/.mise.toml
/home/gdlx/projects/myproject
/home/gdlx/projects/myproject/
/home/gdlx/projects/myproject/.mise.toml
Expected behavior
Unless I misunderstood something, the config file should just be trusted:
mise doctor
outputWith
MISE_TRUSTED_CONFIG_PATHS
unset (I've shown above thattrusted_config_paths
is correctly set when I set the variable):Additional context
I've seen nothing relevant with
--debug
or--trace
.The text was updated successfully, but these errors were encountered: