eza-community / eza

A modern alternative to ls
https://eza.rocks
European Union Public License 1.2
11.92k stars 215 forks source link

Config file? #897

Open Omnikron13 opened 7 months ago

Omnikron13 commented 7 months ago

I think there should really be a config file for this, to set up various defaults and such. Even the colours and what have you that can be tweaked with environment variables, it seems it would surely be better to really have in a config file doesn't it?

I've hacked my way to getting it to behave how I'd like with fish abbreviations and such like, but it seeems weirdly missing like $XDG_CONFIG_HOME/eza.conf (or perhaps even a folder under $XDG_CONFIG_HOME if people might want to have colour/icon themes and such?)

Shouldn't really be that tricky to implement imo, it's more what kind of file format, what options, etc. people would favour?

PThorpe92 commented 7 months ago

This is currently a work in progress, with the first step (a theme.yml file replacing the EXA_COLORS environment variable) PR just being hung up on testing issues.

This is technically a duplicate of #139 but I'll leave it open for discussion on what everyone would like to see feature wise for the eventual config file and ideally so we can get a few theme contributions. I'd really like to be able to offer a handful of pre-made themes to choose from when #840 can get merged. :+1:

PThorpe92 commented 7 months ago

Looks like this will get merged here pretty soon, and with custom icon support both thanks to @gierens :rocket: :rocket:

CouldBeThis commented 5 months ago

I wanted a config file for ages to replace my collection of long shell aliases. A couple of times went looking around in the documentation, repo, online etc trying to find out how to do it.

@PThorpe92 I see #840 which from what I can see is mostly about colors, with an eye to expanding later. I will patiently wait/hope for all the options to be included eventually. And appreciating eza and contributors meanwhile.

I read #139 and while initially wasn't sure if there is really a benefit to config file vs shell alias I found it convincing that there is. Personally I just find things easier to read with linebreaks, comments and divided up into multiple files. Since opinions were solicited here:

Omnikron13 commented 5 months ago
  • I personally find it really helpful when cli tool facilitate the creation of a config file

In the hobby project I've been mucking around with lately, I'm going with a strategy of embedding a commented YAML config file as the source of default values. You can then just handle that the same way as the rest of the config file hierarchy, it centralises the default configuration, users can easily find it in one place in the project repo, and you can very easily add a few lines of code that will spit a copy out for end users.

PThorpe92 commented 5 months ago

@CouldBeThis

Awesome, those are all helpful points!

I believe we will be sticking with yaml. I personally cannot stand JSON for a configuration language, I deal with too much of it at work as it is :sweat_smile:

I also think it's a good idea to be able to load a specific config as a command line argument, and I'd like to have another one that dumps the default config to stdout or a specified location. And I agree the default one should include good comments :+1: I don't really like dumping one at XDG_HOME | XDG_CONFIG, but I think its reasonable to check there for an existing one (if EZA_CONFIG_DIR isn't set, before falling back to the normal configuration previously done from ENV variables.

kfernandez31 commented 2 months ago

Hello, what's the current status of this?

Omnikron13 commented 2 months ago

I don't really like dumping one at XDG_HOME | XDG_CONFIG, but I think its reasonable to check there for an existing one (if EZA_CONFIG_DIR isn't set, before falling back to the normal configuration previously done from ENV variables.

I'm never 100% sure I've grasped it all properly, but I believe according to the Filesystem Hierarchy Specification a file of the defaults should probably go in /usr/share/ (static supplementary files; /usr/ is 'read-only' and so to be supplied by a package or the distro, /usr/share/ for architecture independent files for which default config would generally fall into IME).

Can't say I've written enough thing warranting proper config hierarchy kinda stuff to have really followed this, but as a rule I'd say the de facto 'correct' hierarchy would be something like this:

  1. /usr/share/ - default config from the upstream source of the software.
  2. /etc/ - systemwide configuration from the packagers of the distro.
  3. /etc/[...].d/ - administrator modifications to the systemwide config.
  4. $XDG_CONFIG_HOME/[...]/ - user specific modifications to the config
  5. $XDG_CONFIG_HOME/[...].d - user specific modifications for the specific system. (This is maybe a little shakier, and only really worth considering for certain software where a user is likely to need to tweak their dotfiles per system IMO, or for general completeness in case users might want to for unforseen reasons)
  6. Environment variables - tweaks for a specific shell, script, or session.
  7. Flags - very specific tweaks for a single invocation.
gierens commented 2 months ago

Hello, what's the current status of this?

840 is awaiting review from @cafkafk

finite-state-machine commented 1 month ago

It looks like it's been merged! 🎉

Since I don't speak rust, and since there appear to be no automated tests or sample config files, I have no idea how to use this.

Do we know when some documentation (or anything that would serve as documentation) might be added?

finite-state-machine commented 1 month ago

Looking through the code a bit more closely, it doesn't look like there's a way to specify defaults for most command-line flags yet. 🙁

gierens commented 1 month ago

There is a sample config under docs/theme.yml in the repository and there is also some documentation in the README. And yes you are correct, at the moment it only concerns theming. Configuring icons and styling via a file has been one of the most requested features and that's why we gave that priority for our initial implementation, which still turned out to be a fairly heavy PR. Expanding it to all settings is just going to take more time. Sorry.

finite-state-machine commented 1 month ago

@gierens Thanks for the clarification! I appreciate the wonderful tool you and the other maintainers have built, and appreciate everything you do to improve it!

PThorpe92 commented 1 month ago

This actually brings up a good question.

When adding an actual configuration file instead of just a theme file, is that a place for specifying a default command line argument, considering the ubiquity of shell aliases? If not, what options do we have in the config file?

gierens commented 4 weeks ago

Hm, I don't really see these options as mutually exclusive to be honest. One can specify defaults via the configuration file and use or overwrite those in the shell aliases.