Improve config cmd

[A2va]

Description

Add two major things:

• Generate a default configuration file if one does not exist
• New command to change the options from command-line

Changed the config edit flag as follow:

beet config --edit -> beet config --open
beet config -e -> beet config -o

New flag for editing settings from command-line. Edit flag accept the path of setting, the key must be present in the file.
It's impossible to modify option type (like string to integer). This command support boolean, string, integer and float and other type will be ignored.

beets config --edit=import.write --value=true

To Do

• Documentation. (If you've add a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• Changelog. (Add an entry to docs/changelog.rst near the top of the document.)
• Tests. (Encouraged but not strictly required.)

[sampsyo]

Hi there! Thanks for diving right in and prototyping something! Both of these are interesting ideas.

Broadly speaking, it would be best to discuss the two new ideas independently. At a high level, I'm not sure about automatically creating a new configuration file on every execution—that seems like it could create some unintended side effects for people who don't expect beet version to do anything. A command to modify configuration options is also potentially quite cool, although we'll need to consider exactly how it works closely. config.dump() was never exactly meant for replacing the existing configuration, and the current YAML parser/dumper is not fully "round-trippable": it only makes a reasonable effort to preserve comments, etc. So it will be important to be sure that users can't shoot themselves in the foot with this.

This is far lower-level, but I would prefer to keep the CLI options named the way they are. That is, --edit would continue to do what it does now. For the now "update" option, perhaps we could consider something like --set field=value or --modify, which more closely match other commands/options available in beets?

[A2va]

For now I removed the generation of the configuration file and add flag --set field=value like you suggested,

config.dump() was never exactly meant for replacing the existing configuration, and the current YAML parser/dumper is not fully "round-trippable": it only makes a reasonable effort to preserve comments, etc. So it will be important to be sure that users can't shoot themselves in the foot with this.

I tested the preservation of comments and they are not preserved. So a modification of confuse is needed for that ?

[sampsyo]

Yeah, we would indeed need to somehow do this in Confuse. One option would be tackling beetbox/confuse#52 first because that library (I think??) offers a better route to round-trippable YAML.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This pull request 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.