remove unused black pre-commit hook and blacken docs

[graingert]

Summary of changes

pre-commit is configured in this repo. This means whenever I commit I automatically apply these fixes.
Because pre-commit is not run in CI the compliance has drifted, and so when I commit I get a huge number of changes!

Closes

Pull Request Checklist

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

[somniumism]

@graingert Hi. I'm not the maintainer of this repository, but I'll give you some advice.

Your commits contain too many redundant codes.
So we can't know what the purpose of this PR is and what it's modified.

If you are using VScode, I think the python linter works automatically when you save the files.
You should turn off the option in VScode settings, and then push the commits again.

Please note the tests below that must be passed in order to be merged and the amount of code you have modified(+13,393 −9,314).

[graingert]

@graingert Hi. I'm not the maintainer of this repository, but I'll give you some advice.

Your commits contain too many redundant codes.
So we can't know what the purpose of this PR is and what it's modified.

If you are using VScode, I think the python linter works automatically when you save the files.
You should turn off the option in VScode settings, and then push the commits again.

Hello, first thanks for the advice! However in this case I was simply running "git commit" when these automated changes were applied by the configuration in this repository

[somniumism]

@graingert Hi. I'm not the maintainer of this repository, but I'll give you some advice.
Your commits contain too many redundant codes.
So we can't know what the purpose of this PR is and what it's modified.
If you are using VScode, I think the python linter works automatically when you save the files.
You should turn off the option in VScode settings, and then push the commits again.

Hello, first thanks for the advice! However in this case I was simply running "git commit" when these automated changes were applied by the configuration in this repository

Oops..
I thought the redundant codes was included using the linter, not Black.
But I just run Black with these files you modified, and found out you were right.

I'm not sure if it's okay to include this change because I'm not the maintainer of this repository,
but I'm sorry I gave you advice without even trying and even thinking...

[somniumism]

@jaraco I have a question!
As I talked to @graingert above, can unnecessary codes caused byBlack be included in the commit?

Unnecessary here means that it is different from the original purpose that it was intended to be modified.
This repository states that Black is used as the main linter(code formatter), but there are actually files that are not applied with Black.
ex) setuptools/setuptools/command/easy_install.py

I'm incredibly surprised that 198 files have been modified in this PR, because of Black.

[graingert]

I'd also be happy to draft a new PR with my doc syntax error fixes, and the black configuration removed

[jaraco]

There are many things going on here. This project derives from jaraco/skeleton, so that’s where the black configuration comes from. It’s is meant to be disabled because this project hasn’t actually adopted black yet, though I plan to do so soon. I don’t experience the problems because I haven’t opted in to pre-commit for my local checkout of this repo. Is that an option for now (opt out of pre-commit for Setuptools) or do you have another tool that automatically installs precommit?

[graingert]

@jaraco I use existence of .pre-commit-config.yaml as a call to action to use it

[jaraco]

@jaraco I use existence of .pre-commit-config.yaml as a call to action to use it

Totally fair and reasonable. I guess what I'm asking is that you disregard that call temporarily for this project.

[graingert]

I think it's still worth applying blacken docs though

[jaraco]

I'm slightly opposed to running pre-commit in CI. It will add a new workflow and thus noise to the UI. For example, it will double the number of lines that appear under the actions list:

And while that might seem like a minor annoyance, it's caused me real difficulty when I go to that page to check out the status of a push or tag. When I quickly glance at that page, I have to mentally filter out "pre-commit" lines. I've previously had to do this for a different workflow I'd enabled called "automerge", which I recently removed because it was not useful, and I was relieved that I no longer had to mentally filter out those unhelpful workflow results.

That said, if the best thing to do for a project that has pre-commit hooks is to run them in a workflow, I may consider doing that, but I'd want to do it in jaraco/skeleton, so I'm not having to manage it for each project separately.

I can see that I added the pre-commit hooks in jaraco/skeleton@d0f07a4#diff-63a9c44a44acf85fea213a857769990937107cf072831e1a26808cfde9d096b9. Unfortunately, I didn't leave myself enough breadcrumbs to track what instigated me to add that. I think someone suggested in another project that it's something every project should have and so I adopted it experimentally.

I'd like to ponder this some more, but I appreciate you sharing the suggestion.

[graingert]

Ok I deleted the extra workflow. I still think it's worth doing the doc fixes here

[jaraco]

I agree that a lot of the changes herein are worthwhile. I'm a little less certain about others. In particular, there are two changes that blacken-docs makes with which I'm uncomfortable and likely to revert:

• The conversion of multi-line expressions to single-line expressions clumps the arguments together, making them less distinct and discernible. Especially with documentation, whitespace can really help to convey an idea or to set the stage for a larger block. Consider for example:

  

  In this block, the newlines are there to express that the user should probably have their parameters one per line. Just because they happen to fit on one line is not a good approach, especially when additional parameters are probably going to force the syntax (even when black) to be on multiple lines.

  For actual code, the flux of these transforms is acceptable. For docs, it's an impediment to their core purpose.

• The forcing of the more heavy double-quotes (both by pixels and by keystroke) in contradiction with Python's default repr is unnatural and violates this project's specified opt-out for that change. Unfortunately, due to Tool doesn't honor black preferences adamchainz/blacken-docs#62, blacken-docs doesn't support the few preferences that black supports. For this reason, I'm going to remove blacken-docs from the pre-commit builds (at the skeleton).

I would like to keep the other changes.

I hate to be pedantic for what I imagine you thought was a straightforward and obvious improvement, so I'll accept responsibility to manually back out the unwanted changes.

Thanks for the contrib!

[graingert]

For that specific example you can use ..., to force black to explode that line

[graingert]

It's probably worth finding an alternative to check the syntax of these docs