-
Notifications
You must be signed in to change notification settings - Fork 4
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
Python Linting With black
#358
Conversation
Added an initial GitHub action for linting, currently only contains black formatter for python, but general enough for other linting in the future.
The exact command ran was `black . --line-length 92 --extend-exclude flepimop/gempyor_pkg/src/gempyor/steps_rk4.py`.
6f9bd15
to
3331eb8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code formatting looks fine - one note about the action itself in comment below (for other's to chime in on as well).
One additional ask: can we have an "easy mode" either script or documentation update about how to apply the check on the local end?
.github/workflows/lint.yml
Outdated
on: | ||
workflow_dispatch: | ||
push: | ||
paths: | ||
- '**/*.py' | ||
branches: | ||
- main | ||
pull_request: | ||
paths: | ||
- '**/*.py' | ||
branches: | ||
- main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do we think about restricting this to the package materials, but expanding it to more branches?
I definitely want less non-library code in the repo moving forward, and linting is generally good, but ... seems like it might be an unnecessary headache for operations for the library-adjacent code, while letting too much mess accumulate in library for the operational branches that we want to merge back in.
So to offer opinion on open Qs:
|
Offline discussion between @jcblemai, @pearsonca, and I:
|
Action now triggers on a push to any branch that modifies gempyor for quick feedback and pull request with any modified python files.
Added a quick pre-commit hook that will apply the black formatter with the same params used in the GitHub action.
Updated the documentation to reflect the new usage of `black` and how to use the pre commit git hook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Doc add re process is nice.
8e67ca8
In anticipation of GH-358, minimize future work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really nice quality of life feature, thanks for working on this
Add a utility per @fang19911030 request to apply `black` with the same settings that the GitHub action uses.
71ee9b1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks good to me. Just noting agreement that we should adapt something similar for R code too later down the line.
In anticipation of GH-358, minimize future work.
In anticipation of GH-358, minimize future work.
Describe your changes.
This pull request:
pylint
orruff
or linting for other files like yaml, [Feature request]: YAML Linting #343, or R).black
formatter to the python files contained in the repo. The exact command used wasblack . --line-length 92 --extend-exclude flepimop/gempyor_pkg/src/gempyor/steps_rk4.py
.--verbose
option with theblack
formatter, I view this as a temporary thing as we transition to formatting code and as folks get used to it we can then get rid of it since it is a bit too much output for a GitHub action.Open questions:
pre-commit
but that requires a new tool, or could write some pre-push script but then have to maintain the same actions in more than one place. Thoughts (can also push to an issue if too gnarly for this PR)?steps_rk4.py
that was mentioned by name in the previous PR Initial python linting #282 (comment). I'm sympathetic to the fact that this file is hard to read when line lengths are shorter, but I think this is a sign that it needs to be refactored at some point which is beyond the scope of this issue. For now we can skip it and then address in a dedicated issue?What does your pull request address? Tag relevant issues.
This pull request starts to address GH-279 and replaces GH-282 (I was concerned about making the right git maneuvers to get that into shape since it is over two months old so opting to close instead).
Tag relevant team members.
@emprzy @fang19911030 @jcblemai @pearsonca @saraloo @shauntruelove