Offer option other than pyproject.toml for config

[altendky]

pypa/pip#6163
pypa/setuptools#1642

It seems that pyproject.toml is a trigger for enabling PEP 517 isolated builds. This seems a not good thing to tie to configuration of black. It broke pyinstaller and others with the pip-19.0 release.

[JelleZijlstra]

Sorry for the issues you saw! #688 suggests also supporting setup.cfg, which seems reasonable to me.

[altendky]

There's been a lot of follow up discussion pypa/setuptools#1642 and pypa/pip#6163. I followed in the beginning but can't really give a summary anymore, sorry. It might be worth reading up on where they are going with all this, or maybe it's not and just having another config-file option is appropriate.

I personally don't use black (yet?) so I was mostly just trying to point out the scenario for consideration.

[cjerdonek]

I believe the latest plan is to roll back pyproject.toml triggering PEP 517 builds in a new pip 19.0.x release and to try again in pip 19.1 once the implementation is more tested and known to be more stable.

[leplatrem]

As I wrote in #688 (comment), setup.cfg is a good candidate! It's used by setuptools (thus by pretty much everyone), it's been there for years, and it's used by flake8, coverage, mypy, zest.releaser, ...

Note: see an example in our project where we had to introduce the pyproject.toml just because of black :( BTW our setup.py is only 2 lines long 😉

[zsol]

I'd really like to avoid supporting multiple configuration styles. I think if we go with setup.cfg, we should remove pyproject.toml.

[adamantike]

I can give it a try if nobody has started working on it. However, I'd try to keep both pyproject.toml and setup.cfg options. Otherwise, it will be a breaking change with a major release associated, and will require project maintainers to update their configs, only to keep using the latest version of black.

Is that what everybody wants?

[altendky]

In general, is embedding into something else's config a good thing? Why? Why not a separate file just for black? Yes, coverage can use setup.cfg, it can also use its own file.

[Natim]

I guess having a .black file would be fine.

A while ago the Pythonic world converge in putting everything related to a python project tooling config into setup.cfg (flake8, coverage, wheel, zest.releaser) the whole ecosystem.

Somehow that also a feature of [ini] files to be categorized, so it made sense to have all in one place. If you look at the Pyramid framework the thing we put in the INI file is even wider.

I am not convinced that we should force people into a way of doing things. I wish we could handle INI config files for black, we don't even need to have a default file.

We could put black config in any INI files and add a black command argument such as --config file.ini to specify where the black config lies.

[altendky]

@zsol, just to clarify, are you only against multiple formats? Or also against multiple possible files? For example, would you consider checking for .black (configparser format) then setup.cfg to be one reasonable option? I can see arguments against both of them, though multiple files of the same format seems less troublesome since at least you don't have to deal with multiple possible structures for the config data.

@Natim, I haven't really followed the convergence. Is there anything formal in that regard I/we should read? It looks like coverage and flake8 anyways both offer setup.cfg, individual files, and tox.ini config options.

[leplatrem]

It looks like coverage and flake8 anyways both offer setup.cfg, individual files, and tox.ini config options.

I like this approach very much! It would allow black to fit in most existing projects without imposing too much beyond code formatting ;) Also since it is close to flake8 in terms of tooling, I believe it makes sense to follow their approach and allow both configs to be close to each other!

[zsol]

I'm against multiple formats as well as multiple possible files. My understanding is that flake8 isn't very happy with how their configuration story looks like today. See #65 (comment)

[altendky]

https://github.com/altendky/tempexample/tree/f680fc866c6cf80ed3824b92926e0585e5e0143d

I updated the example failure I provided over in pypa/setuptools#1642. It no longer fails with pip==19.0.3 and setuptools==40.8.0. I don't know if this is a permanent state or not so someone might find it worth reading up on the pip/setuptools side to see what the path forward is.