Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove unused black pre-commit hook and blacken docs #2737

Merged
merged 9 commits into from
Jul 21, 2021

Conversation

graingert
Copy link
Contributor

@graingert graingert commented Jul 20, 2021

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

@somniumism
Copy link
Contributor

somniumism commented Jul 20, 2021

@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
Copy link
Contributor Author

@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
Copy link
Contributor

@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
Copy link
Contributor

somniumism commented Jul 20, 2021

@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
Copy link
Contributor Author

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

@jaraco
Copy link
Member

jaraco commented Jul 20, 2021

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
Copy link
Contributor Author

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

@graingert graingert changed the title run pre-commit in ci run pre-commit in ci, and remove unused black pre-commit hook Jul 20, 2021
@jaraco
Copy link
Member

jaraco commented Jul 20, 2021

@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
Copy link
Contributor Author

I think it's still worth applying blacken docs though

@jaraco
Copy link
Member

jaraco commented Jul 20, 2021

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:

image

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 graingert changed the title run pre-commit in ci, and remove unused black pre-commit hook remove unused black pre-commit hook and blacken docs Jul 20, 2021
@graingert
Copy link
Contributor Author

graingert commented Jul 20, 2021

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

@jaraco
Copy link
Member

jaraco commented Jul 21, 2021

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:

    image

    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
Copy link
Contributor Author

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

@jaraco jaraco force-pushed the run-pre-commit-in-ci branch 3 times, most recently from 1ed1054 to 22cf1c5 Compare July 21, 2021 22:07
@graingert
Copy link
Contributor Author

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

@jaraco jaraco merged commit 1b84724 into pypa:main Jul 21, 2021
@graingert graingert deleted the run-pre-commit-in-ci branch July 21, 2021 22:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants