python / cherry-picker

🐍🍒⛏ Utility script for backporting/cherry-picking CPython changes from master into one of the maintenance branches.
Apache License 2.0
46 stars 38 forks source link

Allow to configure user preferences with a configuration file #45

Open Jackenmen opened 2 years ago

Jackenmen commented 2 years ago

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.