Proposals for global installation

[Firef0x]

Hello, @dohliam !

Appreciate your great work! 🌹 I want to submit this program in Arch User Repository so that Arch Linux users could install it easily with package manager. I've already written the install script, and have some proposals for global installation. The install script can be found in https://build.opensuse.org/package/show/home:firef0x/gdcl .

First, would you please shorten the name of the executable? It is lookup.rb and group.rb now, slightly long. sdcv just names its executable 4 letter long and so does ydcv. I suggest to change the name of lookup.rb to gdcl, and group.rb to gdcg.

Second, there are a number of configuration options at the beginning of the scripts now. If the scripts are installed into /usr/bin, the options would be overwritten after an upgrade by package manager. I think it's better to separate the options from the scripts and group them into a conf file in /etc or ~. The file in /etc or ~ wouldn't be overwritten after an upgrade by package manager. Since most of the program in Linux works in that way, I think it worth a shot.

Do you agree with me? 😅 Hope for your reply!

Yours sincerely! 🙇

[dohliam]

Hi Firef0x, thanks for your interest in gdcl and adding it to Arch User Repository! 😄 I think it's a great idea and agree that the executable name would be better shortened.

(I had originally thought about calling it gdcv, but then decided that it would be better to leave that name in case the Goldendict folks decide to make an official version. 😃 ) But gdcl is fine.

I totally agree that the config options should be separated out into their own file. I had been thinking about using a yaml file for this (in the same directory as the executable), but if it's going to be installable/upgradable of course we want to avoid it being overwritten every time there is an upgrade, so either something in home or /etc makes sense.

To avoid cluttering up the user's home directory, something like ~/.config/gdcl might work (that seems to be the standard place for new programs these days). What do you think?

[dohliam]

Keeping this issue open until proper config files are set up

[Firef0x]

Hello, @dohliam !

Glad to see that the executables is renamed. 😀 I've updated the install script accordingly. However, I decided to install gdcl.rb as gdcl and gdcg.rb as gdcg like what ydcv does, for users don't need to know which language the executable is written in. (But the developers do need)

It's a good practice to obey the XDG Base Directory Specification, putting the YAML file in a subdirectory of $XDG_CONFIG_HOME. (i.e ~/.config/ in most case) So I totally agree with you! (〃ω〃)

Yours sincerely! 🙇

[dohliam]

Fixed as of 79a9853

[Firef0x]

Hello, @dohliam !

Many thanks! However, it's not appropriate to install something in user's home directory by package manager. Since package manager serves as a global manager, not just for a specific user. It's a better way to install the config file into /etc or just do nothing.

I propose that gdcl should support reading config.yml from $XDG_CONFIG_DIRS (i.e. /etc/xdg) or somewhere in the /etc, so that package manager could install the default config.yml into /etc for all users and no error message shows in their first use. Note that most package manager could handle the changes of config files in an upgrade.

Do you agree with me? Hope for your reply!

Yours sincerely! 🙇

[dohliam]

Hi Firef0x, thanks for the feedback. If I'm understanding you correctly, we could have the script read the config.yml file first from ~/.config/gdcl if it exists, and if it doesn't exist, it could then look in /etc/xdg/gdcl for a default config file. If that file doesn't exist either, it would then check in the same directory as the executable (for those who are not installing through a package manager, but just downloading the source files directly).

So the priority for config.yml would be:

1. ~/.config/gdcl/
2. /etc/xdg/gdcl/
3. ./

Would that work for you? Let me know and I'll make the changes ASAP.

[Firef0x]

Hello, @dohliam !

Yes, exactly! The priority is correct and this is the way most of the programs in Linux work in.

However, I have a question. Do I have to include all options in config.yml to keep the program working? For example, if I have installed /etc/xdg/gdcl/config.yml through the package manager, and a user just want to change the value of :default_group: "" to his preference. Does he need to copy the whole file config.yml to directory ~/.config/gdcl/ and make the change? Or he just need to create an empty file config.yml in ~/.config/gdcl/ and add the following line:

:default_group: "en"

Hope for your reply!

Yours sincerely!

[dohliam]

8f77596 should resolve this issue. When run for the first time, the script looks for config.yml in the user home, $XDG_CONFIG_DIRS, and the script executable folder itself (in that order). If it can't find the file in ~/.config/gdcl, then it creates that directory and a copy of the default config.yml file so that the user can edit it themselves. This should answer your last question -- just run the script once and then edit the file in user home. This way, users can see examples of configuration options as well as explanations of what they are for.

[Firef0x]

If you have a copy of config.yml in your xdg config directory or somewhere else (e.g., if you installed gdcl through a package manager), you should avoid editing that file as it will be overwritten when upgrading the package.

I think you misunderstand me. Package manager would not overwrite /etc/xdg/gdcl/config.yml in an upgrade, if user has changed something in /etc/xdg/gdcl/config.yml, it would ask user to merge their change into the new config file (in the upgrade package). It's very safe.