Kubernetes module triggers without env vars about starship HOT 3 CLOSED

I submitted a PR that should hopefully fix this: #5979

from starship.

https://github.com/andytom/starship/blob/cce9d335095a10e7f53cb5c6e54d27d3ce8ac1e1/src/context.rs#L247C1-L252C10

    /// Returns true if `detect_env_vars` is empty,
    /// or if at least one environment variable is set and no negated environment variable is set
    pub fn detect_env_vars(&'a self, env_vars: &'a [&'a str]) -> bool {
        if env_vars.is_empty() {
            return true;
        }

-> if it is unset, it default to "enable", making the check

https://github.com/andytom/starship/blob/4b1cda66417cec0ff146dadf8c673ef7198e919a/src/modules/kubernetes.rs#L132C1-L135C1

    if !is_kube_project.unwrap_or(true) && !have_env_vars {
        return None;
    }

always enabling the module.

I guess the fix is intergrating the detect_env_var into the scanner so one can set the default in case all detection variants (files, folders, extensions, env vars) are unset, instead of setting it separately for files/folders/extension and env vars.

A workaround if you only want to get triggered by a file is set the env var to something invalid:

[kubernetes]
disabled = false
detect_files = ['.k8s']
# Not setting it would enable it always in v1.19.0: https://github.com/starship/starship/issues/5978
detect_env_vars = ['INVALID']

from starship.

I can confirm this behavior: it was fine with 1.18.2, but now the above happens in 1.19.0.

(EDIT: Earlier it seemed to me that python also exposes this behavior, but there it was due to the detection of the activated env)

from starship.