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

Allow to configure user preferences with a configuration file #45

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Jackenmen
Copy link
Contributor

@Jackenmen Jackenmen commented Aug 8, 2021

Description

Fixes #37

Draft because this still needs tests, testing, and documentation (documentation probably won't be added here until this solution is accepted).
The proposed solution for storing user preferences was not approved by anyone either so that might still change too if the maintainers don't agree with my proposal.

How does this work?

Now onto how this is supposed to work... User can add a configuration file at ~/.config/cherry_picker/preferences.toml which looks like this:

[global]
upstream_remote = "the_real_deal"
pr_remote = "mine"
push = false
auto_pr = false

[global.--continue]
push = true

[local."/home/jack/CPython"]
upstream_remote = "python"

[local."/home/jack/CPython".--continue]
auto_pr = true

Preferences override themselves in this order (the last on the list has the highest priority):

  1. Global configuration
  2. Global configuration for --continue
  3. Local configuration
  4. Local configuration for --continue
  5. Arguments passed in CLI

// It might perhaps make more sense to swap 2 with 3 but this order was just how I ended up implementing it so I'm just leaving it as is until I get feedback on this :)

Other notes

In issue #37, I said:

The most obvious solution seems to be using git config since it supports both global and local user configuration already, it is used by cherry-picker already, and therefore should be relatively straightforward.

But I figured that making a TOML file is actually easier to implement and maybe faster? Using git config would require either using a lot of subprocess calls to get all the configuration or parsing the output of git config --local --list, and its nesting support is limited to 3 levels, i.e.:

cherry-picker-preferences.global.upstream_remote=true

which might be fine but is definitely limiting.

@Jackenmen Jackenmen force-pushed the user_preferences_file branch 2 times, most recently from 28746ba to f576357 Compare August 14, 2022 17:27
@Jackenmen
Copy link
Contributor Author

Pinging @gpshead as the author of #4 and @markshannon as the author of #19 since I imagine you may both have some interest in this feature due to its practicality over specifying those options through CLI flags.

If you have anything to share on the solution shown here (as described in the PR description - the code is mostly inconsequential and is not covered by tests anyway) then I'd very much appreciate it to know, if this is the right direction for it. When I originally made this (it's been 3 years ago apparently, time flies 😄), I delayed completing the PR with test coverage and such since I had absolutely no clue if this would be accepted but I'd been reminded last week that it still exists so trying to move this forward.

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

Successfully merging this pull request may close these issues.

Add a way to configure user preferences
2 participants