Kubernetes module triggers without env vars

[weseven]

Bug Report

Current Behavior

The kubernetes module is triggering with this configuration although there is no .k8s file in the current directory:

❯ tail .config/starship.toml 
add_newline = true

[directory]
truncation_length = 4

[kubernetes]
disabled = false
format = '[k8s\($context\)](dimmed green) '
detect_files = ['.k8s']

Upon investigation, this might be caused by the recent addition of detect env vars with #4488

Configuring detect_env_vars, e.g. with

detect_env_vars = ['KUBECONFIG']

restores the correct behavior (the module is not triggering if there is no file and the env variable is not defined)

Expected Behavior

Not defining the detect_env_vars option should not trigger the module.

Possible Solution

I imagine the env var detection done here https://github.com/andytom/starship/blob/4b1cda66417cec0ff146dadf8c673ef7198e919a/src/modules/kubernetes.rs#L110 either is faulty or should only be triggered if the relevant config option is present in the starship configuration.

Environment

• Starship version: 1.19.0
• bash version: GNU bash, version 5.2.26(1)-release (x86_64-redhat-linux-gnu)
• Operating system: Fedora 40.0.0
• Terminal emulator:
• Git Commit Hash:
• Branch/Tag:
• Rust Version: rustc 1.78.0 (9b00956e5 2024-04-29) (Fedora 1.78.0-1.fc40)
• Rust channel: release
• Build Time: 2024-05-15 00:00:00 +00:00

Starship Configuration

format = """
$username\
$hostname\
$localip\
$shlvl\
$kubernetes\
$directory\
$vcsh\
$git_branch\
$git_commit\
$git_state\
$git_metrics\
$git_status\
$memory_usage\
$env_var\
$custom\
$sudo\
$cmd_duration\
$line_break\
$jobs\
$status\
$os\
$container\
$shell\
$character"""

command_timeout = 1000
add_newline = true

[directory]
truncation_length = 4

[kubernetes]
disabled = false
format = '[k8s\($context\)](dimmed green) '
detect_files = ['.k8s']

[jankatins]

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)

[jankatins]

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']

[davidkna]

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