I’m hoping this is me being oblivious (yet again)....
# general
f
I’m hoping this is me being oblivious (yet again). I’m using ruff. When I says
pants lint scripts::
for subdirectory
scripts
I get no errors, but when I run
pants lint ::
I get errors for files in that directory. (mostly include order, but that might be a red herring) Any hints?
w
I just ran into something like this last night. In my case, I think it had to do with batching, but I was getting stuff that seemingly worked, but then I run the command slightly differently, and it failed. A consistent repro would be nice, as I wasn't able to get Pants to do it. I did also notice that
fix
would mark the repo as fixed, but
lint
would fail - because some of the autofixes are "unsafe". Not sure of the best approach to letting the user know what's up. You can try upping the batch size maybe, and see if you get consistent pass/fails as a sanity test?
f
is batch size a ruff setting?
w
https://www.pantsbuild.org/stable/reference/goals/lint Lint setting. e.g.
pants lint --batch-size=1024 --only=ruff-check ::
f
Thanks. That didn’t help. The repo is really not that big. I have a feeling that ruff is being run differently (or different ruffs). However, I’m going to ignore the check for now and punt the problem down the road.
w
If you can come up with a reproduction repo, that would help. I'd like to figure this out too, but mine was a heisenbug for sure
h
This is the ruff version of the famous isort problem, where the tool infers first- vs third-party packages by inspecting the code presented to it. So different input sets can lead to different inference. The workaround is to tell ruff explicitly which are your first-party package names (if that is tractable in your case).
And several discussions of this on this Slack (search for "isort")
isort/ruff expecting to receive the entire world as input is at odds with Pants's sandboxing model
w
in that case, the batch size thing should have worked to put them all in the same sandbox though. Is there an easy way to limit certain tools to be single-process over the repo?
h
These are two different "them alls" though
pants lint ::
presents the entire repo to ruff
pants lint scripts::
just a subset
This isn't related to batching I think
w
In my case, it was behaving differently because Pants was split into like 4-6 batches, then I remember trying as 1 batch, and I got different lint errors
All using
::
I think
f
I wasn’t able to change the behavior in my first try with the ruff settings. I’ll have to come back to it
w
👍 I've been mildly experimenting with running non-modifying code in the workspace, rather than always building a sandbox. That could be interesting, and would definitely be faster 😄
h
The issue with that is that you might cache against a different version of the file, if the user was modifying while Pants was running
So that should be behind a "--faster-but-dangerous" flag or something
E.g., in CI it would be totally fine, but on the desktop it might be risky
w
Yah, for sure. But, ruff also takes like, 500ms to process a workspace - so at some point, you're trying to break it
And it would essentially emulate how these tools are used for users today, so, let the dev determine the risks - offer max perf 🤷
h
If we turned off caching we'd be emulating how these tools are used today
Well, selectively turned off caching
w
Yeah, caching and sandboxes, which is a bit much. Tom's already done a lot of the in-workspace work, so, making some of this available could be interesting. Or, more to your point, in CI especially
Anyways, there's a long list of perf stuff - just one of many things - but I think there are more fundamental improvements which might allow the best of both worlds