You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, all of my test configurations are colocated within my tox.ini file for my entire project, except for my black configuration for line count = 120, which is stored in our pyproject.toml, and is the only setting configured there.
Describe the solution you'd like A clear and concise description of what you want to
happen.
Instead of having path a pyproject.yml and a tox.ini, I would like to be able to include the black configurations directly with tox.ini.
Describe alternatives you've considered A clear and concise description of any
alternative solutions or features you've considered.
I can't seem to find any single type of configuration file that works for pytest, pylint, bandit, flake8, and black. Tox is supported by the most of these, so I am trying to chase this down.
Reacted by Mike, François Vieille, Maurice (mausy5043) Hendrix and rkrisztian
I don't think we should do this. pyproject.toml is a standard(ish) way of configuring Python tools, while tox.ini is specific to Tox. Instead, other tools should move towards allowing configuration through pyproject.toml.
Reacted by John Hagen, Łukasz Langa and Manoj Baishya
Do you happen to know what about the pyproject.toml standard is different then the tox.ini standard? Particularly why the header names I use in tox.ini seem to break black's ability to process the tox.ini?
If someone added something like this to their pyproject.toml, it would also start to cause black to fail. But I am not familiar enough with pyproject.toml's standard to understand what makes it incompatible?
Not too familiar with it, but obviously one is in TOML format (which is a standardized language) and one is in .ini format, which I think is just whatever Python's configparser module accepts.
Also, there is negative traction towards expand pyproject.toml to other tools, particularly mypy. But going to chat in that thread and see if mindset has changed at all.
@dciborow I don't use Tox so I wouldn't know for sure, but the main difference causing them to be incompatible is probably that tox.ini uses the INI file format which is different enough from the TOML file format. pyproject.toml is just a normal TOML file who's contents has been somewhat standardized for Python's packaging usage (and now also tools under the [tool.*] namespace).
I don't think our TOML parser can just ignore a misconfigured value / table. That sounds complicated and prone to errors. In your case, the problem is that booleans values must be lowercase in TOML. And allowing Black to run even when the configuration fails to parse sounds dangerous. It could format files it should never format because it was unable to read the exclude option configured in that invalid file.
Understand the points you are presenting. But to be super clear, the black configuration between the two files is identical.
So to be clear on the reverse point that I am trying to make... if a pyproject.toml is misconfigured outside of the [tools.black] section, you would expect black to fail? Even when the black section is completely correct and readable by black?
I think the below case fails just because [mypy] is missing "tool.".
Where I am proposing black can ignore those sections, instead of failing on them.
Activity
dciborow commentedon Apr 30, 2021
Currently... we are able to put this in a plain tox.ini, and everything works.
It is only when we add more things to tox.ini, that it stops working.

JelleZijlstra commentedon Apr 30, 2021
I don't think we should do this.
pyproject.tomlis a standard(ish) way of configuring Python tools, whiletox.iniis specific to Tox. Instead, other tools should move towards allowing configuration throughpyproject.toml.dciborow commentedon Apr 30, 2021
@JelleZijlstra ,
Do you happen to know what about the pyproject.toml standard is different then the tox.ini standard? Particularly why the header names I use in tox.ini seem to break black's ability to process the tox.ini?
If someone added something like this to their pyproject.toml, it would also start to cause black to fail. But I am not familiar enough with pyproject.toml's standard to understand what makes it incompatible?
so, a different way to look at this... Should an existence of a misconfiguration in a different setting break black in the pyproject.toml?
JelleZijlstra commentedon Apr 30, 2021
Not too familiar with it, but obviously one is in TOML format (which is a standardized language) and one is in
.iniformat, which I think is just whatever Python'sconfigparsermodule accepts.dciborow commentedon Apr 30, 2021
Also, there is negative traction towards expand pyproject.toml to other tools, particularly mypy. But going to chat in that thread and see if mindset has changed at all.
python/mypy#5205
JelleZijlstra commentedon Apr 30, 2021
Actually mypy is about to gain support for pyproject.toml (python/mypy#10219).
ichard26 commentedon Apr 30, 2021
@dciborow I don't use Tox so I wouldn't know for sure, but the main difference causing them to be incompatible is probably that tox.ini uses the INI file format which is different enough from the TOML file format. pyproject.toml is just a normal TOML file who's contents has been somewhat standardized for Python's packaging usage (and now also tools under the
[tool.*]namespace).I don't think our TOML parser can just ignore a misconfigured value / table. That sounds complicated and prone to errors. In your case, the problem is that booleans values must be lowercase in TOML. And allowing Black to run even when the configuration fails to parse sounds dangerous. It could format files it should never format because it was unable to read the exclude option configured in that invalid file.
dciborow commentedon Apr 30, 2021
@ichard26 ,
Understand the points you are presenting. But to be super clear, the black configuration between the two files is identical.
So to be clear on the reverse point that I am trying to make... if a pyproject.toml is misconfigured outside of the [tools.black] section, you would expect black to fail? Even when the black section is completely correct and readable by black?
I think the below case fails just because [mypy] is missing "tool.".
Where I am proposing black can ignore those sections, instead of failing on them.
pyproject.toml
JelleZijlstra commentedon Apr 30, 2021
We're just using a TOML parser. If the TOML is valid, we use it. If it's not valid, we don't, because we can't.
dciborow commentedon Apr 30, 2021
okay... let me do some more debugging... see if its something else in my .ini thats messing this up.
It sounds like @JelleZijlstra , you would not expect the above sample to fail for black, given it was a valid TOML...?
dciborow commentedon Apr 30, 2021
ahhh turns out this was my problem line.
tox.ini allows...
follow_imports = silentBut pyproject.yml wants
follow_imports = 'silent'and 'silent' breaks .ini

13 remaining items
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project
black: Add black to project