feat(config): Support --config in pyproject.toml

[Shivansh-007]

Description

You can now specify config key in pyproject.toml which does the same job as the CLI option --config. The path of config should be relative to the CWD it is running from. If the file is not found or is invalid i.e. it is a folder rather a TOML file it would raise click.exceptions.FileError, and if the file can't be parsed it would raise tomli.TOMLDecodeError. All black config keys in the custom config should be registered under [black] and they would overwrite the config specified in pyproject but not the one specified by --config flag while running black with the CLI.

I also did a small update to .gitignore by grouping the "test" and adding htmlcov to it. Which is generated by coverage html and .pytest_cache/ produced when you run pytest ..

Closes #1826

Checklist - did you ...

• Add a CHANGELOG entry if necessary?
• Add / update tests if necessary?
• Add new / update outdated documentation?

[felix-hilden]

Thanks for getting this started as well!

Couple of discussion points:

• I think a path relative to the original TOML's location should be better, right? That way the run wouldn't depend on where you executed Black, as it is currently.
• How about just overriding the configuration instead of trying to merge it?

[ichard26]

I haven't taken a deep look at the code nor played with the feature locally but I do quickly want to mention we should probably somehow indicate we using a configuration file via indirection in verbose mode. Honestly I'm not sure what's up with the weird merging / overriding behaviour here, but I'd suggest to keep it simple for now and just treat a config value in config file (regardless if was explicitly given or implicitly discovered) as a HTTP 302 redirect.

[Shivansh-007]

Question: Should the config be overwritten if it is passed through the CLI option --config? The config = "black.toml would be found in that file (which is passed through the CLI).

[ichard26]

I'm confused by what you mean, can you further explain what scenario we're talking about here? Do you mean whether --config at the command line should override just the config value in the implicitly discovered configuration file or instead override the use of that file? In that case I'd suggest to ignore any implicitly discovered configuration files as that's what passing --config at the command line does today.

[Shivansh-007]

There are two ways configs are loaded, (1) they are passed by the user through --config flag and (2) the pyproject.toml is found in the src. So currently when we find the config key we check whether if it is found by the config found in pyproject.toml or it is found in the one passed by the user via --config option. I am not sure why I did this originally, so I was asking should I keep this check or just overwrite it in any case. I would go with the latter.

[ichard26]

So currently when we find the config key we check whether if it is found by the config found in pyproject.toml or it is found in the one passed by the user via --config option

Ah this is relevant because you handled those two cases differently. I'd say treat them the same as a HTTP 302 redirect but for configuration for simplicity. If the config key was found in pyproject.toml, ignore the rest and switch to the file specified. Same thing with the --config option, if present, just start the configuration loading process at its filepath. I feel like adding another merging rule on top of the "CLI options override options defined in a configuration file" merge rule will just overcomplicate things. Afterall --config is intended as an explicit way to force Black to use a specific configuration file (instead of searching for one) and nothing more. If the configuration file specified by --config contains a config key, then switch configuration files, kinda like a game of hot potato :p

Also you know we're on Python Discord right? It might be easier to discuss in the #black-formatter channel ^^

[Shivansh-007]

Yeah, I am on discord also (Jason Terror#XXXX) but currently, off from it until my exams ended, I have a break between the next ones till the 17th so opened these PRs - didn't want to keep them hanging, school ones just finished. And discord as you know, can become a big distraction LOL

[felix-hilden]

Richard also raised a good point about chaining this value in the original issue. I tend towards chaining being supported, which would require a loop of some sort to follow the TOML files.

Also, I think it would be more consistent to just require all TOMLs to have the same structure, i.e. a tool.black section instead of some other magical section. That way we could probably simplify the implementation and also solve chain cycles by looping through the files with an iteration threshold.

[Shivansh-007]

By chaining do you mean you can specify config in the custom black config file you got from pyproject.toml, and so on (allowing to specify config in that config file...)?

[felix-hilden]

Looking better already, here's some comments:

[ichard26]

I did not do a hands-on test as I'm far too annoyed right now to do so but here's some initial feedback. We also need to check the pypy coverage drop.

[JelleZijlstra]

This has a merge conflict without an obvious fix, could you take a look?

[JelleZijlstra]

@ichard26 are you happy with this PR now?

[danielmitchell]

This PR appears to have stalled? It would be great if it could progress since there are a couple of related issues (#1826, #2863) it will resolve and make black much easier to configure in a monorepo.

[ichard26]

Hey all, I'll try to review this soon (especially since IIRC I had some outstanding comments I never shared the last time I looked at this), but I can't make promises.

[jaklan]

@ichard26 any chance to push it forward?

[AbdealiLoKo]

I was looking for the usecase described in #1826 and came across this PR
Would be great if this can be released!

If I can help with something to push this forward, I'm happy to help

[alfawal]

@ichard26 Just a reminder to take a look please.

[hauntsaninja]

See also #1826 (comment)