Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a config for default behaviour #156

Open
ondrejfuhrer opened this issue Apr 14, 2020 · 7 comments · May be fixed by #174
Open

Add a config for default behaviour #156

ondrejfuhrer opened this issue Apr 14, 2020 · 7 comments · May be fixed by #174
Assignees

Comments

@ondrejfuhrer
Copy link
Collaborator

ondrejfuhrer commented Apr 14, 2020

As a user I would like to set a default behaviour to brew cu command. As an example I might wan't to always run it with --all option.

Desired flow:

> brew cu
==> Options
Include auto-update (-a): false
Include latest (-f): false

Config change

> brew cu config set auto-update true
Option "auto-update" has been set to "true" by default.
> brew cu
==> Options
Include auto-update (-a): true
Include latest (-f): false

Options overview:

  • brew cu config set KEY VALUE - sets a certain value to the key
  • brew cu config reset KEY - resets certain key to a default state
  • brew cu config reset - resets all keys to a default state
  • brew cu config list - prints all configs
  • brew cu --ignore-config - running brew cu command in a default state (as there are no configs set)

Available keys:

  • auto-update - if auto-update apps should be updated
  • latest - if "latest" apps should be updated
  • interactive - always run the upgrade as interactive
  • force-yes - always update all the apps (no interaction needed)
@muescha
Copy link
Contributor

muescha commented Apr 14, 2020

what about a dotfile like .brewcu config file (in current dir and in your ~/ home dir

there i can set all options with like on command line

i would also expect only this new commands:
brew cu -f ./current_config_file
brew cu --ignore-config

order:
1 command line options
2 ./.brewcu
3 ~/.brewcu

@ondrejfuhrer
Copy link
Collaborator Author

ondrejfuhrer commented Apr 14, 2020

Hey @muescha , thank you very much for your feedback! I really appreciate that.
It would anyways use a dotfile (or some sort of config file in the home dir) to store those options, so what you are suggesting is very much possible. And true that probably the implementation would be much easier and adding the manipulation through brew cu config commands can be added later on.

Regarding the order:
Do you see a use case where you would like to have a different behaviour based on the execution context? Wouldn't that bee too confusing?

brew cu -f ./current_config_file

Also do you see a valid use case here, having multiple settings?
PS: -f is already taken, therefore it would be more likely -c and --config

@muescha
Copy link
Contributor

muescha commented Apr 14, 2020

i was just thinking in general about commands and their .dotfiles and where i expect it to read from which places and in which order.

Do you see a use case where you would like to have a different behaviour based on the execution context? Wouldn't that bee too confusing?

you are right we can remove that 2 ./.brewcu

brew cu -f ./current_config_file

Also do you see a valid use case here, having multiple settings?

maybe in a ci environment or something like this but you are sure i don't know where it is needed

@ondrejfuhrer ondrejfuhrer linked a pull request Sep 5, 2020 that will close this issue
@muescha
Copy link
Contributor

muescha commented Sep 22, 2020

should the pinned file also go somewhere here near the .brew-cu ... maybe in as a .brew-cu-ignore file?

@ondrejfuhrer
Copy link
Collaborator Author

@muescha I was also thinking about it and the "issue" I have with it is that this gets not cleaned after uninstalling. The cu command configuration is fine to be "persistent", it is basically a saved preference how you want to use it, but pinned info is more about a state. Therefore when you uninstall the tap the state should be removed as well, what do you think?

@muescha
Copy link
Contributor

muescha commented Sep 23, 2020

but if someone save his ".dotfiles" maybe he like to remember all the pinned files also. so i expect it there and not in a "magic" hidden folder 🤔

@muescha
Copy link
Contributor

muescha commented Sep 23, 2020

but i think thats can be done in a different PR and not for this change... sorry for highjacking this PR with the idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants