`eget` does not respect `eget.toml` when installing package that is represent in the config

[Kenya-West]

System (please complete the following information):

• OS: linux
• GO Version: absent
• Pkg Version: dev-5b1d67b5

Describe the bug

eget does not respect eget.toml when installing package that is represent in the config. Tried with babarot/gomi.

To Reproduce

1. Create ~/.config/eget/eget.toml with this contents:

[api_cache]
  cache_time = 300
  enable = false

[ghproxy]
  enable = false
  host_url = ""
  support_api = true

[global]
  cache_dir = "~/.cache/eget"
  proxy_url = ""
  system = ""
  target = "/usr/local/bin"

[packages]

[packages.gomi]
  repo = "babarot/gomi"

2. Set location to ~:

Set-Location ~

3. Install the babarot/gomi by eget:

sudo eget install babarot/gomi

🚀 Install babarot/gomi from repo
📦 Asset https://github.com/babarot/gomi/releases/download/v1.6.3/gomi_Linux_x86_64.tar.gz
Downloading [====================] 5.05M/5.05M
✅ Extracted gomi to gomi

4. It installs the package to ~, not the /usr/local/bin, as set in [global] section of the eget.toml

Expected behavior

It should install to /usr/local/bin, as written in config file.

[inhere]

Thanks for the detailed report.

I checked the current config loading and install option merge path. When eget loads the expected config file, [global].target is applied to direct repo installs such as eget install babarot/gomi.

The likely cause here is the use of sudo:

sudo eget install babarot/gomi

Under sudo, the process may run with HOME=/root, so eget looks for the config at:

/root/.config/eget/eget.toml

instead of your user config:

~/.config/eget/eget.toml

If the root config does not exist, eget falls back to the default output behavior, which explains why it extracts to the current directory.

Could you try this workaround and confirm whether it installs to /usr/local/bin?

sudo EGET_CONFIG="$HOME/.config/eget/eget.toml" eget install babarot/gomi

This explicitly tells the root process which config file to use.

If that works, then the issue is specifically about config discovery under sudo, not about [global].target being ignored after the config is loaded. We can then decide whether eget should detect SUDO_USER / SUDO_UID and read the original user's config automatically, but that needs a careful rule because it changes config lookup behavior for privileged installs.

[Kenya-West]

Yay! Thanks for precise response @inhere. I really forgot of context, profile and $pwd switching when using sudo!

🚀 Install babarot/gomi from repo
📦 Asset https://github.com/babarot/gomi/releases/download/v1.6.3/gomi_Linux_x86_64.tar.gz
Downloading [====================] 5.05M/5.05M
✅ Extracted gomi to /usr/local/bin/gomi

You are right, this causes the "bug". It is actually not a bug; this is a feature of Linux.

I might close the issue since my case is resolved.