Relative paths for --black-config setting

[peterjc]

Consider we have a user's "global" black configuration in ~/repositories/black.toml and multiple projects under this folder, where ~/repositories/project/.flake8 contains:

[flake8]
black_config=../black.toml

Then, you might run:

cd ~/repositories/project/
flake8 tests/
cd tests/
flake8 .

Both the above should find the ~/repositories/project/.flake8 file, which will load ../black.toml as the location of the black configuration file, which should be converted relative to ~/repositories/project/.flake8 giving ~/repositories/black.toml.

However, now suppose the users does the following, where the command line setting will override any values set via the flake8 configuration files (see https://gitlab.com/pycqa/flake8/issues/560 for clarifying this):

cd ~/repositories/project/
flake8 --black-config ../black.toml tests/
cd tests/
flake8 --black-config ../../black.toml .

Here the relative paths ../black.toml and ../../black.toml should both be interpreted relative to the current directory, and both give ~/repositories/black.toml.

However, if the plugin just gets a string ../black.toml or ../../black.toml, how is it to infer the starting path (a config file location or the present directory)? i.e. How was the setting given (which config file, or was it the command line)?

Cross reference https://gitlab.com/pycqa/flake8/issues/561

If we can't tell, we could be pragmatic and just try both, and maybe give an error if both interpretations exist but are different paths?

[peterjc]

There seems to be a problem with the expected flake8 solution of using normalize_paths=True https://gitlab.com/pycqa/flake8/issues/562

[peterjc]

Flake8 v3.8 changed the behaviour and a unit test now fails with:

$ flake8 --select BLK without_pyproject_toml/*.py --config=flake8_config/flake8
...
ValueError: Plugin flake8-black could not find specified black config file: --black-config ../with_pyproject_toml/pyproject.toml

The file contains black-config = ../with_pyproject_toml/pyproject.toml which is valid if resolved relative to the configuration file, but fails if resolved relative to the CWD which seems to be the new deliberate behaviour: https://gitlab.com/pycqa/flake8/-/merge_requests/363