hcavarsan / kftray

manage multiple kubectl port-forward commands, with support for UDP, K8s proxy, and github state sync.
https://kftray.app/
MIT License
739 stars 70 forks source link

Support XDG Base directory specification #261

Closed InSuperposition closed 2 months ago

InSuperposition commented 2 months ago

Is your feature request related to a problem? Please describe. To improve organization of files and consistency of file paths, support XDG Base directory variables https://wiki.archlinux.org/title/XDG_Base_Directory

Describe the solution you'd like Support the XDG_* variables as an alternative to using $HOME/.kftray on Linux and OS X. Perhaps it should be the default, if variables are set..

hcavarsan commented 2 months ago

hey @InSuperposition thx you for the suggestion, it makes sense.

its easy to implement something like that, and from what I have seen in the lib in this code: dirs-rs, it follows the XDG_* standard only for Linux.

do you use these variables on linux and osx? cuz on osx it will respect the $FOLDERID_ variable and in this case and might not have the desired effect in your case.

i can create a workaround to explicitly check for the XDG_ variables on Unix-based systems and use them even on osx....

wdyt?

InSuperposition commented 2 months ago

Thanks for the information on dirs-rs. I use the XDG_* variables on osx, while this is not standard by convention, it helps my OCD of keeping an organized $HOME folder 😉

I have noticed many CLI tools (git) and terminal apps (alacritty, kitty) support the XDG_ vars on osx, however tools that use dirs-rs like starship use custom environment variables for config (and cache/state etc..): export STARSHIP_CONFIG=$XDG_CONFIG_HOME/starship/config.toml.

After thinking it over, IMO, the safest approach might be to have a KFTRAY_CONFIG variable the user can set similar to starship. I can open a ticket in the dirs-rs repo and make the suggestion to add the XDG_* vars for osx to their code base and get feedback from the developers of that library, who have more insight regarding this feature.

hcavarsan commented 2 months ago

yeap, that makes sense. I will try to implement the logic and read the XDG_CONFIG_HOME variable without using the library (and fallback to $HOME). I think it's quite simple. I will look into this during this week and will update you here on the issue, so there's no need to open an issue on dirs-rs. thanks!

InSuperposition commented 2 months ago

Thank you, I appreciate the effort you have put into kftray.

hcavarsan commented 2 months ago

hey @InSuperposition,

ive released a new version here: v0.12.1 Release.

I implemented reading new environment variables and refactored the code to be more readable. Now, all the directory configuration logic is located here:.

kftray now reads three environment variables to check the app's configuration directory, following this order of precedence:

  1. KFTRAY_CONFIG
  2. XDG_CONFIG_HOME
  3. HOME

if any of these variables are set, the new version also includes an alert to identify and notify the user of any duplicate configurations. Here’s an example of the alert:

image

my env vars:

env | grep -i HOME

HOME=/home/henrique
XDG_CONFIG_HOME=/home/henrique/.config

note: if you are running kftray as a regular os application, to read the variable, it needs to be a global environment variable. on osx, you can probably achieve this with launchctl setenv environmentvariablename environmentvariablevalue.

could you verify if this setup now works and functions correctly for you?

thx

InSuperposition commented 2 months ago

This change worked for me. Thank you!