Support XDG Directory Structure

[sashokbg]

Hello,

It would be nice if the tool supported XDG directory structure as described in in freedesktop org:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Example: binaries in ~/.local/bin, configs in ~/.config etc

Thank you for your project,
Cheers !

[ahmetb]

I'm personally not sure if this is worth doing and introducing yet another way that's different to reason about specific to Linux. Previous proposals in kubectl project has stalled/rejected. kubernetes/kubernetes#97885, kubernetes/enhancements#2229 ... If more important tools aren't following XDG convention, making Krew to do so is not very useful. We offer facilities like KREW_ROOT env var that lets you customize installation path (where binaries and configs go etc), so that may help to some extent.

[sashokbg]

Hello, you say "specific to linux" but are there any other non *nix OS that you have in mind ?

Would you accept a PR if I find the time to do it ?

[ahmetb]

Krew is fairly frequently used on Windows and MacOS so I'd prefer directory locations are uniform across these for easier support and documentation. Xdg is yet another thing to learn for maintainers and reason about during support requests.

If kubectl (a fairly sophisticated tool that reads/writes a lot of config/state on local disk) doesn't follow suite, why do you want Krew (a much smaller project) to support it? Shouldn't you/we be going after the bigger fish if XDG is a case worth convincing people?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[SuperSandro2000]

If kubectl (a fairly sophisticated tool that reads/writes a lot of config/state on local disk) doesn't follow suite, why do you want Krew (a much smaller project) to support it? Shouldn't you/we be going after the bigger fish if XDG is a case worth convincing people?

To not litter the home directory with yet another directory.

[sashokbg]

Even microsoft supports XDG hihi 😄

At this point programs that do not support it are more like the exception..

Let's try to make all this conversation more productive:

If we make the changes and propose a PR that will make the tool work in both XDG and non XDG environments would you be willing to accept it ?
It seems to me this way everyone would be happy.

[ahmetb]

Even Microsoft does it is sadly not a good argument. I'm less interested in the code itself and I explained my concerns above. Many existing users have ~/.krew dir already present and added to path, and these should not break. This also complicates the documentation aspects (like printing out a message to tell the users to add a specific directory to PATH after the installation).

I'd be happy to see a thorough design (not necessarily code) that handles these cases and explains how it would work.

[sashokbg]

Hello @ahmetb yes I understand your concerns, I was thinking about having it work for everyone so that nothing breaks for existing users and everyting is completely transperent and seamless.

Check the two flow charts I sketched:

I think these two cover all cases and will make it work for everyone.

• People who don't have XDG env just continue using $HOME/.krew
• People who have XDG and are freshly installing use $XDG_CONFIG_HOME/krew
• People who have XDG but have config in $HOME/.krew can continue using it "as-is"
  • When they update their config will be moved to $XDG_CONFIG_HOME/krew

Thank you once again for the great project and please let me know what you think.

P.S I made the Microsoft comment just for a laugh :) I agree it is not a good argument hehe !

Kind Regards
Alex

[mgoodness]

Hello @ahmetb yes I understand your concerns, I was thinking about having it work for everyone so that nothing breaks for existing users and everyting is completely transperent and seamless.

I believe this is how Git did it ~8 years ago.

[maverick1872]

I'd also love to see this. I understand the support concerns as maintainers have to know/understand/reason about these things; but these are defined conventions generally speaking for the Operating Systems.

These defined conventions are the follow if I'm not mistaken:

Mac OS: ~/Library/Preferences
*nix: ${XDG_CONFIG_HOME:-${HOME}/.config}
Windows: %APPDATA%

Given the above from a support perspective you can still always refer users their configuration directory via something along the lines of this.

Configuration can be easily accessed via the env var ${KREW_ROOT}. This env var is OS dependent and is provided as a shorthand to access the krew configuration in the OS defined configuration directory.
Mac OS: ~/Library/Preferences/krew
*nix: ${XDG_CONFIG_HOME:-${HOME}/.config}/krew
Windows: %APPDATA%/krew

This provides a handful of benefits in my opinion. Users can always safely assume where to look for configurations given OS conventions are followed by default. Then on the flip side maintainers can always reference the provided configuration dir env var and generally not have to be concerned as to where the configuration actually lives.