-
Notifications
You must be signed in to change notification settings - Fork 0
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
Use Poetry for dependency management #148
Changes from all commits
67d3daf
1d70c76
49a006b
70831ff
0cd42cc
dfa7ac1
bd53021
1fc9a4c
e12154d
d20f5ed
e7b4200
a4f157e
62d428e
957dbc9
f349d8d
a64c4bd
bb2f7d4
8f26f7b
4b7a1b0
5e37b8f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,11 +5,11 @@ on: push | |
jobs: | ||
black: | ||
|
||
runs-on: ubuntu-20.04 | ||
runs-on: ubuntu-22.04 | ||
|
||
steps: | ||
- uses: actions/checkout@v2 | ||
- uses: actions/setup-python@v2 | ||
- uses: actions/checkout@v4 | ||
- uses: actions/setup-python@v4 | ||
- uses: psf/black@stable | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've found it better to install Black (with a specific version) as a dev dependency on and invoke it using Python in the workflow script and from the command line or IDE when developing. Otherwise different versions of Black disagree on their defaults ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you point to a similar config in another repo that we could adopt in this one? (I'm not finding a lint.yml in any other repositories). My approach to using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is possible that Black has settled down lately, but in the past it changed its default settings from release to release. Which caused angst when it changed under you -- potentially hundreds of changes in a formerly Black-compliant codebase. Hence version pinning. And making it part of the dev deps, so that everyone working on the repo, plus the workflow, is using the same Black, always. I've noticed that Black checks are often the last step of the Python CI workflow. For example, in pycds. I believe this is because a failing Black check can cause your unit tests to be cancelled, and this can be undesirable. I think I recall discussing this with Nik a while back when we were both working on the same repo. In any case, it is common practice in our projects. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd argue that it's a good thing for black checks to be done first since they are the cheapest and that we consider them to be important for controlling code quality. If there is a specific version of black that we should pin to, please feel free to recommend it :) |
||
with: | ||
black_args: ". --check" |
This file was deleted.
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.
The existence of v4 is worth mentioning to all of us in Zulip or at the next team meeting. Are there any noticeable differences?
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.
I didn't research any differences... just saw a deprecation notice w.r.t. v2 so I upgraded to the most recent version. It's probably worth mentioning to folks, even if I'm not very well informed about it aside from "it works!".