-
-
Notifications
You must be signed in to change notification settings - Fork 568
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
CI / tox: Update and speed up pyright #36443
Changes from all commits
bbc099f
aa50168
dce6b1f
02bd361
ccf8a20
8d686d6
f7dcfce
0dedbf9
385a3e4
8129558
8852022
05e34ef
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 |
---|---|---|
|
@@ -103,20 +103,9 @@ jobs: | |
MAKE: make -j2 --output-sync=recurse | ||
SAGE_NUM_THREADS: 2 | ||
|
||
- name: Set up node to install pyright | ||
if: always() && steps.worktree.outcome == 'success' | ||
uses: actions/setup-node@v3 | ||
with: | ||
node-version: '12' | ||
|
||
- name: Install pyright | ||
if: always() && steps.worktree.outcome == 'success' | ||
# Fix to v232 due to bug https://github.com/microsoft/pyright/issues/3239 | ||
run: npm install -g [email protected] | ||
|
||
- name: Static code check with pyright | ||
if: always() && steps.worktree.outcome == 'success' | ||
run: pyright | ||
run: ./sage -tox -e pyright | ||
working-directory: ./worktree-image | ||
|
||
- name: Clean (fallback to non-incremental) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -22,4 +22,7 @@ | |
"reportUndefinedVariable": "warning", | ||
"reportOptionalOperand": "warning", | ||
"reportMissingImports": "warning", | ||
"reportPrivateImportUsage": "warning", | ||
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. Why not fixing the single instance of this error (by properly importing the offending method)? 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 didn't see the immediate fix, and it did not seem worth it. 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 don't remember the names, but sage is importing x from y, and y is importing x from z (without reexporting it). So just import x from z. 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. We don't even have such a thing as a convention of what reexports should look like in Sage. So warning instead of error is quite appropriate. 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. Here 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 don't plan to work on this import. If you want to fix stuff, just open a PR. |
||
// Suppress because it flags our standard pattern @staticmethod __classcall__(cls, ...) | ||
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. comments in json files are sadly not possible. the common workaround I've seen is to add them as another field, i.e. 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's a Microsoft extension ("JSONC"), see https://github.com/microsoft/node-jsonc-parser |
||
"reportSelfClsParameterName": "none", | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
# This type-stub file helps pyright understand the decorator @lazy_attribute. | ||
|
||
# Adapted from https://github.com/python/typeshed/blob/b9640005eb586afdbe0a57bac2b88a7a12465069/stdlib/builtins.pyi#L1237-L1254 | ||
class lazy_attribute: | ||
def __init__( | ||
self, | ||
f: Callable[[Any], Any] | None = ... | ||
) -> None: ... | ||
def __get__(self, a: Any, cls: type) -> Any: ... |
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 still think that this way of installing pyright is better. I also don't get the consistency argument (as it comes down to calling pyright without any other arguments). Tox just installs (and calls) pyright in a very convoluted way. And this is exemplified by the memory issues. What to you think about using https://github.com/jakebailey/pyright-action? Also has the advantage of adding problem matchers
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.
It comes down to not only that, but also to running the same pyright version, on the same Node version.
There's nothing convoluted about it. This is how one installs and runs pyright using Python infrastructure without having to rely on a system installation of Node.
And there is nothing mysterious about "memory issues", it is a default heap size of 2 GB, which is too small for our purpose. Here I configure it explicitly so that proper function does not depend on an externally set configuration.
I looked at it, as you had mentioned it before. As I explained in the PR description, adding Check Warnings for pyright's complaints just makes no sense.
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.
Yes, but we have a node environment here, so no need to use the Python infrastructure. I'm aware that its more convenient for the average Python dev to run it that way locally. But that doesn't mean the ci needs to do that way, and in fact the node-setup action is the githuby way of installing node in a github workflow. So please use it.
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.
No, there's not only "one way" of doing things right.
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.
You can also easily disable comments for the pyright action if that's your concern. I would say we should run it twice: once without commenting for all functions, and a second time with comments on type-annotated functions.
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.
Beyond the scope of this PR.