Change code formatting to black #7458
Conversation
JacobCallahan
added
DO NOT MERGE
enhancement
|
@SatelliteQE/quality-engineers Please check out the example changes in this PR. This will NOT be the final code to be merged when the change happens, as that should also include some additional pieces. |
|
@JacobCallahan Formatting looks way better than flake8 and as it supports autoformatting its a cherry on cake. :) Btw Travis is upset with you :( |
|
@jyejare yeah travis will be much less upset when the flake checks are removed! |
|
@JacobCallahan we can still keep flake8 to warn about things like unused imports, unused variables etc.. Black can live with flake8 as long we ignore some specific checks example: https://github.com/rochacbruno/dynaconf/blob/master/.pre-commit-config.yaml#L35 |
|
@rochacbruno I have not used yet. But https://pypi.org/project/flake8-black/ |
|
@SatelliteQE/robottelo-automation I've updated this PR with the new pre-commit hook. |
JacobCallahan
changed the title
Codecov Report
@@ Coverage Diff @@
## master #7458 +/- ##
==========================================
- Coverage 67.96% 67.93% -0.03%
==========================================
Files 30 30
Lines 3814 3814
==========================================
- Hits 2592 2591 -1
- Misses 1222 1223 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Note that engineers will still need to run black before committing, as it follows the non-changing standard.
Some people might misunderstand it in the same way I did, so to clarify:
You don't have to install and run black manually. black will be run during pre-commit run (or git commit, if pre-commit hook is installed), and it will modify files in repo. What it won't do is staging these changes.
So your workflow might be: git add, git commit (pre-commit runs black, black modifies files), git add again (to stage changes done by black), git commit again (to actually commit, as hook should now pass).
Also, black and pre-commit are still optional. If you don't use them and write code that doesn't conform to black liking, travis will fail for you. So you don't have to use these tools, it's just you will set yourself up for more work than it's worth.
SatelliteQE/robottelo-automation
For the record, this group is collection of random people, including 4 that don't even work on Satellite anymore. If you want wide distribution of your comment, you are better of using SatelliteQE/quality-engineers, which at least contains most of team members.
|
@mirekdlugosz you can use |
| @@ -0,0 +1,17 @@ | |||
| [tool.black] | |||
| line-length = 99 | |||
There was a problem hiding this comment.
OMG! I am on the 79 team.. but I think I can try to accommodate 99 now that I have a widescreen monitor.
|
Ok, so I ran a bunch of automation runs and couldn't find any failures linked to this PR. There is another issue I've identified, so we may want to wait on resolving that. The solution to the other problem might be easier to find before this is merged. |
|
@rochacbruno @mshriver @mirekdlugosz So the issue in our standalone doesn't seem to be affecting our tiered automation runs in 6.7. If you all don't have any reservations, we should be safe to merge. |
JacobCallahan
force-pushed
the
black
branch
2 times, most recently
from
1fd27f6
to
774907c
Compare
This change adds python black to the pre-commit hook. Additionally, it adds pyproject.toml to configure black. This configurations is largely default, but I did skip string normalization. Additionally, line length is capped to 99, per flake8.
Initial formatting of robottelo to the new black standards. Note that string formatting is not changed, and line length is now out to 99, to conform with flake8 settings.
This PR is a demo for the proposal to switch robottelo's code formatting
away from flak8 standards and over to python black.