You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When enabling sorting imports in e.g. pyproject.toml, there are cases ruff cannot categorize an import to be StandardLibrary, FirstParty, or ThirdParty, because it does not see a full source tree.
Version
Development (host) and target OS/architectures:
Output of bazel --version: bazel 7.2.1
Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file: v1.0.0-rc4
bazel test //path/to:ruff_test would fail because ruff cannot find foo.py so it categorized it as a ThirdParty, which means it wants this instead:
importfooimportknown_third_party
Any other information?
After a closer look at this, it seems lint_ruff_aspect only populates srcs to be in the sandbox source tree, which means only src/foo_test.py is in the source tree, not deps.
It's easy enough to pass ruff the transitive sources as inputs. I'm curious if you know of other cases where they are needed? The downside is that a file edit will now invalidate lint actions for all reachable nodes in the graph, making it slower.
If app/main.py imports from lib/helper.py, then edits to helper.py will now invalidate the linting for the py_library or py_binary in the app/ folder now, where previously it wouldn't.
That's potentially okay - it's required for type-checkers to behave this way. But, if it's only to support a few sorted imports appearing differently, then it's too bad to burn engineers time and compute resources on a lot of re-linting when a base library changes.
What happened?
When enabling sorting imports in e.g. pyproject.toml, there are cases ruff cannot categorize an import to be StandardLibrary, FirstParty, or ThirdParty, because it does not see a full source tree.
Version
Development (host) and target OS/architectures:
Output of
bazel --version
: bazel 7.2.1Version of the Aspect rules, or other relevant rules from your
WORKSPACE
orMODULE.bazel
file: v1.0.0-rc4Language(s) and/or frameworks involved: Python
How to reproduce
Consider a simple source tree as the following:
where
foo_test.py
has imports like:pyproject.toml
:And the following bazel stuff:
bazel test //path/to:ruff_test
would fail because ruff cannot findfoo.py
so it categorized it as a ThirdParty, which means it wants this instead:Any other information?
After a closer look at this, it seems
lint_ruff_aspect
only populatessrcs
to be in the sandbox source tree, which means onlysrc/foo_test.py
is in the source tree, not deps.It also doesn't help having:
because it would just be two separated ruff invocations, one with
foo.py
in source tree and the other one withfoo_test.py
in source tree.Another thing to point out is,
lint_ruff_aspect
does not support havingpyproject.toml
not in project root. I left a comment here.The text was updated successfully, but these errors were encountered: