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

Blacken entire project #100

Merged
merged 3 commits into from
Jun 6, 2019
Merged

Blacken entire project #100

merged 3 commits into from
Jun 6, 2019

Conversation

TillerBurr
Copy link
Collaborator

Blacken the entire project. Solves #87.

@TillerBurr TillerBurr requested a review from jwag956 June 5, 2019 21:58
Copy link
Member

@jwag956 jwag956 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what do I/we need to do to actually use this? This change looks like it verifies as part of pytest - but what (if any) options to actually format?
Should we place black as part of 'test_requires'?

Should we be cool and add a badge to our README: https://github.com/python/black#show-your-style?

Other than that - looks good...

setup.py Outdated
"pytest-cov>=2.5.1",
"pytest-flakes>=3.0.2",
"pytest-mongo>=1.2.1",
"pytest-pep8>=1.0.6",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we still need this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of that one.

@TillerBurr
Copy link
Collaborator Author

Black shouldn't be part of tests require. The CI tests would fail for python less than 3.6. pytest-black actually skips the formatting checks if black is not available. The only thing you can modify is the line length.

I completely forgot about linting though. I'm thinking about flake8 or pylint (for things like unused imports.) I'm going to do another commit, but it gets tricky with the long key:value pairs(two factor change method password conformation in core.py)

To actually use this, the only thing that needs to be done is run black on the files. Than run linting, fix errors and ignore lines if necessary.

@TillerBurr
Copy link
Collaborator Author

TillerBurr commented Jun 6, 2019

Maybe some precommit hooks should be added in order to force linting and such. Don't be afraid to create other pull requests, it's fairly easy to run black and lint the files and add exceptions.

@jwag956
Copy link
Member

jwag956 commented Jun 6, 2019

Thanks - so what precisely do I (and other contributors) need to do? I.e. could you at least in the commit explain/point to links that explain how to conform? Maybe this is the first paragraph of a 'developers' RST documentation???

flakes is still part of the pytest/setup line - what else are you thinking? We can always improve - just don't want to backslide.

@jwag956
Copy link
Member

jwag956 commented Jun 6, 2019

I dont think we should add a precommit hook - that basically forces people to do development a particular way - we already have PRs that run CI - so that will catch anything we need.

We have pytest-flakes - so that is a basic linter and since your CI ran succeeded it means you managed to get things right.
As for names like 'two factor change method password conformation' that is simply painful - we should change the name - it isn't really 'change_method' anyway it for changing anything in your 2FA profile (and I am working on opt-in mode). So we could just change that to tf_confirm_password ...

@TillerBurr
Copy link
Collaborator Author

I'll work on a CONTRIBUTING.rst for this. Not much is required, except running black on the code and making sure that flake8 isn't throwing errors.

pytest-flakes really only catches logical errors, not things like unused imports. flake8 incorporates pyflakes (pytest-flakes is based off of this) and pycodestyle (formerly pep8, which is what pytest-pep8 is based on).

Copy link
Member

@jwag956 jwag956 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like what you are doing - however could we break this into separate PRs so we don’t mix simple formatting change with new setup and build and develop changes?
Let’s get black in first - then we can look into changing over to new packaging (which presumably we don't need setup.py anymore)?

Thanks

CONTRIBUTING.rst Outdated
automate installation of virtualenvs and requirements.

.. like this:
mkvirtualenv -p /usr/local/pythonz/pythons/CPython-2.7.11/bin/python coverage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bad example? python 2.7?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a bad example, I'm probably going to remove that. Just an artifact from a contributing.rst (coverage.py) that I found.

- replaces pytest-pep8 and pytest-flakes
@TillerBurr
Copy link
Collaborator Author

Fair enough. Removed the Contributing docs for now. I'm still looking at Poetry for building. Currently, I just use it for the virtualenv management and dependency resolution.

@jwag956 jwag956 merged commit 721d31e into master Jun 6, 2019
@jwag956
Copy link
Member

jwag956 commented Jun 6, 2019

closes: #87

@jwag956 jwag956 deleted the blacken branch June 13, 2019 02:39
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

2 participants