Yay: Revamp config system

[Jguer]

Origin

373

Constraints

• Most Configuration libraries are overkill for yay

Requirements

• Only output configuration file if default values are override
• Exported configuration must only contain overridden default values
• All relevant directories must be checked for existence and created on initialization.
• Configuration variables should only be set on yay init and yay should only read the values thereafter
• Easy to add new flags/config options
• Testing for the config system
  
  
  
  • Test for missing files
  
  
  • Test for missing directories
  
  
  • Test for illegal inputs on file
  
  
  • Test reading of a full, empty and semi-filled config file.
  
  

[Morganamilo]

Does this include moving away from json and to something key pair?

[Jguer]

I was thinking of adding it as a requirement but I think we shouldn't tie ourselves to it if there is a better alternative.

One requirement I did forget was a test suite.

[Morganamilo]

I do prefer key = value over json for configs, I just use --flag --save anyway though it shouldn't matter that much.

One think I've wanted for a while but avoided because it breaks compatibility is separating the build files from pkg and package. So instead of ~/.cache/yay/name/PKGBUILD It would be separated out to ~/.cache/yay/build/name/PKGBUILD and ~/.cache/yay/pkg/name.pkg.tar.xz.

This gives more control over cache cleaning and will make #178 easy to implement with the keep last x version stuff.

[Jguer]

I like it, I suppose it won't break as much as expected if moving config systems. All I do to configure yay is yay -Syu --devel --timeupdate --save so underlying format is not so important to me but #373 (although technically not a problem of legacy configs) did show the limitations of the current system.

Off-topic: Waiting a bit more but still thinking of doing a small hotfix release today. I don't expect anything else to be broken

[Morganamilo]

Also if we do anything that breaks stuff I'll put together a .install that warns the user that their config settings have been reset and they may need to be reconfigured.

[Morganamilo]

Now that we depend on go-pacmanconf we can use the sub package https://github.com/Morganamilo/go-pacmanconf/blob/master/ini/ini.go to implement a pacman style config. With no extra dependencies.

[Jguer]

yay.conf it is :)
Want to handle it or want me to do it, I should have a bit of time for it

[Morganamilo]

You can do it, if it's just in a separate branch I can still send PRs to it. See https://github.com/Morganamilo/go-pacmanconf/blob/master/parser.go for an example of using ini.

[Jguer]

I've started work on it, I was thinking with this new config system should we abandon --save, have a default /etc/yay.conf aka emulate pacman config entirely or implementing write equivalent to go-pacmanconf/ini

My yay.conf test sample
https://github.com/Jguer/yay/blob/reimplement-config/testdata/yay.conf

Feel free to suggest changes, I'm not sure I'm entirely happy with it

[Jguer]

Also if I could direct your attention to https://github.com/Jguer/yay/blob/implement-parser/config.go the change in the configuration structure could change a lot of things so I would also like your take on it.

[Morganamilo]

We're already throwing out backwards compatibility so any changes in the struct shouldn't really matter. I don't get why you need the maps though.

One thing I'd like to do is put all of our config stuff in the struct (before I kept out the not savables to not confuse them with the json) eg targetMode.

Also a couple notes on theexample. How about SortMode = instead of the two individual options? Also a [command] section for PacmanBin ect?

[Jguer]

The maps allows for example the expandEnv just to range through the keys, also provides a clear separation of savables and not savables. But it's very little advantages and can be rolled back

[Morganamilo]

You still have to read each option into the map individually. You could just put the expand env into the parser callback.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.