Apply black styling to all but vendored modules.

[jaraco]

Summary of changes

Includes enforcement of the style via pytest-black.

Note the config changes in pyproject.toml.

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[jaraco]

Oh, FFS.

Ruff is now failing in easy_install and test_wheel because lines are too long:

>           raise RuffError(stdout.decode())
E           pytest_ruff.RuffError: setuptools/command/easy_install.py:254:89: E501 Line too long (89 > 88 characters)
E               |
E           252 |                 'dist_fullname': self.distribution.get_fullname(),
E           253 |                 'py_version': py_version,
E           254 |                 'py_version_short': f'{sys.version_info.major}.{sys.version_info.minor}',
E               |                                                                                         ^ E501
E           255 |                 'py_version_nodot': f'{sys.version_info.major}{sys.version_info.minor}',
E           256 |                 'sys_prefix': self.config_vars['prefix'],
E               |

I guess ruff counts the carriage return and black doesn't?

[jaraco]

I think it's just a coincidence that the line length is 89. I've tried longer lines and black will create longer lines as long as it's a string that's exceeding the line length, so manual intervention is needed to prevent black from exceeding the line length limit.

For example, black will also reformat this to be too long:

class C:
    dict(
        file_defs={
            "foobar":
                "The quick brown fox jumped over the lazy dog........................",
        }
    )

[abravalheri]

Thank you very much for working on this Jason.

I suppose that it is better to rip off the bandaid and make the code base consistent with the code formatting once and for all.

Am I correct in assuming that the test suite will also make sure that the formatting is consistent in future changes?

[abravalheri]

Should we add all the 3rd party and autogenerated code here as well? (i.e. the folders: setuptool/_distutils and setuptools/config/_validate_pyproject?)

I have a doubt, will ruff also follow this config?

[jaraco]

Maybe? My instinct is not to add it until needed. I'm pretty sure _distutils follows black now... and since _validate_pyproject isn't complaining, let's let it get the black treatment until it becomes untenable to do so (upstream introduces incompatible syntax).

I would not expect ruff to follow this config, but it seems to be satisfied by the default config, so I'm inclined to stick with it.

[abravalheri]

(Brainstorming)

In a future change, we probably want to rewrite this using f-strings to make it more readable, there are some line breaks that don't make much sense. It would also be nice if we can replace pkg_resources with improtlib.resources.

[jaraco]

I do agree with using f-strings. I've observed that pyupgrade --py38-plus automatically converts most formatting strings to f-strings, so maybe we should re-consider running that across the codebase.

[jaraco]

Am I correct in assuming that the test suite will also make sure that the formatting is consistent in future changes?

Yes. pytest-black does that and pytest-enabler will enable pytest-black unless disabled (e.g. -p no:black).

[jaraco]

I should also point out that adding this change and check makes it easier for me to develop using an IDE that automatically applies black styling on save (avoids the need to format with black and commit before applying a meaningful change).