Skip to content

BUG: resolve invalid grep with env neutral script #29551

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

lvllvl
Copy link
Contributor

@lvllvl lvllvl commented Aug 12, 2025

Attempts to resolve #29538

Copy link
Contributor

@tylerjereddy tylerjereddy left a comment

Choose a reason for hiding this comment

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

This does seem to fix the issue described in the ticket for me locally on (ARM) Mac.

I added a few small comments in case they help.

+ r")(?!\w)")

NOQA_OK = "noqa: borrowed-ref OK"
NOQA_MANUAL = "noqa: borrowed-ref - manual fix needed"
Copy link
Contributor

Choose a reason for hiding this comment

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

I suppose it is minor, but some of these module-level variables get used directly in functions without passing them in, which is a bit global-like. I wonder if it might make sense to pass them through. I guess it matters less for non-library code--I might be slightly tempted to just pass them through main and to the function that uses them from there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok I'll move these global variables to the main function.

return 2

exts = set(args.ext) if args.ext else set(DEFAULT_EXTS)
excludes = set(args.exclude) if args.exclude else set(DEFAULT_EXCLUDES)
Copy link
Contributor

Choose a reason for hiding this comment

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

these DEFAULT_.. vars are already sets, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, I'll adjust these as well. Currently these are global vars but I'll bring them into main.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, I'll adjust these as well. Currently these are global vars but I'll bring them into main.

suffix=".txt",
dir=tmpdir
)
os.close(fd)
Copy link
Contributor

Choose a reason for hiding this comment

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

I suppose we could try to use a context manager to avoid the manual resource handling

"--ext",
action="append",
default=None,
help="File extension(s) to include (repeatable). Defaults to .c,.h,.c.src,.cpp",
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if it would make sense to just substitute the variable in directly here to avoid hardcoding the defaults in two separate locations, i.e.,

--- a/tools/ci/check_c_api_usage.py
+++ b/tools/ci/check_c_api_usage.py
@@ -148,7 +148,7 @@ def main(argv: list[str] | None = None) -> int:
         "--ext",
         action="append",
         default=None,
-        help="File extension(s) to include (repeatable). Defaults to .c,.h,.c.src,.cpp",
+        help=f"File extension(s) to include (repeatable). Defaults to {DEFAULT_EXTS}",

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok making this change.

tools/linter.py Outdated
borrowed_res = subprocess.run(
["bash", borrowed_ref_script],
["python3", borrowed_ref_script],
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be slightly safer to use sys.executable here? I'm reminded of a recent discussion (scipy/scipy#23334) about preferring that in general with spin.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok added this sys.executable in the script

@@ -0,0 +1,211 @@
#!/usr/bin/env python3
from __future__ import annotations
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this just needed in case someone is using an older Python version than we normally support outside of linting?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I think intiially the issue popped up because I didn't think about a certain environment where this script may be used. So I thought maybe this would be helpful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am open to removing this. I don't know if my initial assumption is correct or appropriate for the codebase. But lmk what your preference is here.

@lvllvl lvllvl requested a review from tylerjereddy August 14, 2025 16:49
@lvllvl
Copy link
Contributor Author

lvllvl commented Aug 18, 2025

Hi @tylerjereddy, I made a few changes based on your comments. Please let me know if any other changes are needed before I can merge this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: grep: Invalid option -- P when running spin lint on macOS
2 participants