Fixes #57 runs black & isort for code formatting check

[kushaldas]

Ready for review

Fixes #144.

Adds new lint targets for black and isort tool.

make lint will now first check any isort change and then black
and then flake8. All 3 commands use line length of 100.

The last commit also adds a .git-blame-ignore-revs file,
so that we don't see the changes from the formatting commit in the
git blame output.

How to test manually?

• go back to the first commit in this PR git checkout f9bcbd3e8b49b737b2b85bf608f48349ddc68a4b
• make black
• make isort
• make lint

All of the above make commands should fail as formatting change is required.

• move to next commit git checkout 787844dc339e090aa0e9ac2241895365522c4119
• make black
• make isort
• make lint

All of the make commands should now pass. Please note down a few lines in the different files changed in this commit for the next test. Use git blame to get the details.

• move to the latest commit git checkout 32e62719148d54d1c264e8b781056803fa46b24a
• git config blame.ignoreRevsFile .git-blame-ignore-revs run this command.
• git blame should not my name in the lines changed in the last commit.

extra notes

Here is one fail message from black.

$ make lint
would reformat /home/kdas/code/securedrop-proxy/securedrop_proxy/proxy.py
Oh no! 💥 💔 💥
1 file would be reformatted, 8 files would be left unchanged.
make: *** [Makefile:32: black] Error 1

[rmol]

Looks good to me, but Black requires Python >= 3.6, so we should probably update setup.py to match. With a 3.5 virtualenv, pip won't be able to find Black.

Also, for some reason the Unicode flair is displayed as tofu in my Qubes development VM, though I tried several fonts and a couple of terminal emulators, some combinations of which definitely worked on regular Debian. Not a blocker. 🤷‍♂️

[kushaldas]

Looks good to me, but Black requires Python >= 3.6, so we should probably update setup.py to match. With a 3.5 virtualenv, pip won't be able to find Black.

I am marking it as Python >= 3.7 as we are running and testing on 3.7 in Debian Buster.

[rmol]

Python version requirement looks good, but I realized something else: our Flake8 configuration uses a line length of 100. For now we should probably add a pyproject.toml adjusting Black's line length to match our current convention.

[kushaldas]

@rmol I added pyproject.toml and also a new commit after running black on the source.

Note: except securedrop none of the other projects have any flake8 configuration from our side.

[kushaldas]

Okay, CI is failing to build the package because pip/setuptools is using PEP 517 to build via pyproject.toml, means we can not have it here. Instead I will add .flake8 and mark the maximum line length to 88 as in default black.

10:22:13 | <pradyunsg> | dh_virtualenv...
10:22:19 | <pradyunsg> | pip._internal.exceptions.DistributionNotFound: No matching distribution found for setuptools>=40.8.0
10:22:19 | <pradyunsg> | Installing build dependencies ... error
10:22:38 | <pradyunsg> | It's trying a PEP 517 build for some package that has a pyproject.toml.
10:23:00 | <pradyunsg> | And I don't think dh_virtualenv was ever updated for this.

@rmol @redshiftzero

[eloquence]

We agreed to hold off until this change for now until a cross-repo code style standardization conversation, which is scheduled for after the SecureDrop Workstation pilot launch.

[eloquence]

This is ready to be picked up again; note that we want to use 100 characters line length.

We've also agreed that we want to use an ignoreRevsFile for any commits to enforce black (whether in this PR or a follow-up one). On current master:

$ black --check -l 100 .
would reformat /home/erik/Code/securedrop-proxy/setup.py
would reformat /home/erik/Code/securedrop-proxy/securedrop_proxy/entrypoint.py
would reformat /home/erik/Code/securedrop-proxy/tests/test_entrypoint.py
would reformat /home/erik/Code/securedrop-proxy/securedrop_proxy/proxy.py
would reformat /home/erik/Code/securedrop-proxy/tests/test_proxy.py

[kushaldas]

This is ready for review, the description has the new steps for testing.

[rmol]

👍

One thing I tripped over was that isort's list of third-party packages is derived from the active virtualenv, so developers will need to ensure their editor or IDE is using the project-specific virtualenv, or they might get unexpected results from isort.