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

Fixed #34140 -- Format python code blocks in documentation files under docs/releases #16487

Closed
wants to merge 4 commits into from

Conversation

jvzammit
Copy link
Contributor

@jvzammit jvzammit commented Jan 19, 2023

Ticket #34140 -- part of it

What have I done?

This is a "child" of #16261

As discussed in there (long comments thread, sorry) I applied the:

  1. manual changes for blacken-docs to work
  2. the changes by blacken-docs command

in two separate commits.

Edit: Third commit fixes an error that I couldn't replicate locally with make html -- it needed the whole sphinx-build command. I expect this commit to be squashed on merge.

In order for the PR to not be huge, I worked on and applied the changes only to the docs/releases directory (and all its children).

So the objective of this PR is twofold:

  1. Agree that this is the right direction going forward. If it is, we can split the work into separate PRs based on structure of the docs and the current output of blacken-docs command when ran over the whole docs directory.

2. Merge this PR Release notes will not be changed as part of this effort.

Thanks for the help so far @carltongibson @felixxm @adamchainz @pauloxnet @benjaoming @smithdc1

@pauloxnet
Copy link
Contributor

I think the release notes are perhaps the only exception to code formatting because they reflect very old versions of the code based on very old Python versions. I would leave them as the last step if not completely excluded from this activity.

@jvzammit
Copy link
Contributor Author

@pauloxnet I agree, makes sense. What do you think about the approach? I.e. steps 1 & 2 above?

@carltongibson
Copy link
Member

Thanks for this @jvzammit! I didn't get to it this week, but you're on my list for next. 🎁

@pauloxnet
Copy link
Contributor

pauloxnet commented Jan 19, 2023

What do you think about the approach? I.e. steps 1 & 2 above?

Steps 1 & 2 make sense to me, maybe we can start from a small module and see what happen.

@jvzammit
Copy link
Contributor Author

Closing in favour of #16496

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants