https://pantsbuild.org/ logo
Join Slack
Powered by
Related question :point_up: if I have a linter tha...
# plugins
a
Related question ☝️ if I have a linter that operates at the repository level, not the target or file level, is that an appropriate thing to use a pants plugin for? Looking at the lint goal, I see a LintTargetsRequest and a LintFilesRequest, which makes sense in the context of Pants' model. Before I go and subclass AbstractLintRequest, is this just a perverse thing to do in pants? For context, tach is a tool for checking that module dependency rules are not violated. I know that I can do this through Pants itself, but the DX is a little painful. 
tach check
uses a toml file to check the dependencies of declared modules, and make sure that we haven't accidentally imported a gajillion ML libraries into the wrong place. It would be nice to have it work under 
pants check
.
g
Does it have to work on the repository level; or is that just how it's normally used? I.e, could it run just on one file (with whatever necessary config files it needs)?
a
I think it does, yeah. There's no option for "check this file only"
Which I guess makes a certain sense, but violates pants' mental model completely
g
Copy code
tach_module(
    dependencies=[<via inference, all nested python_source>]
)
If you then get the transitive closure of all those sources dependencies, you would pull in all places where you would see edges passing out of your module. I guess the question is... does tach need to see non-violated edges? i.e., if it says you can't depend on 
<http://foo.app|foo.app>
, and 
<http://foo.app|foo.app>
isn't in scope and thus not in the sandbox... is that ✅ or ❌ ?
could obviously do something like 
tach_workspace()
which depends on all tach_modules too, if it needs to see all code.
That is roughly the model I did for my rust plugin fwiw, though I simplified a bit by having a single recursive sources target, not multiple.
a
Ja... I'm coming to the conclusion that being able to run tach under 
pants check
is not worth the effort compared with, yunno, installing tach separately and running it standalone in CI.
I'd quite like to just use pants dependency rules but they had some rough edges when I played around.
Like every command failing, eg. "no pants test until you go fix this dependency", or the fact that a single violation is an immediate termination of pants, so you can't see a list of the violations.
g
I did a very ugly hack for a complex test a long while back which was to pull a pex + a tool pex into a shunit_test, then run it as a shunit test. It's not quite what you're asking for, and I'm not sure what the mechanics would be to pull all Python sources. But in theory, maybe it could work. 🙂
I'd be worried about source roots with running it standalone, but maybe you don't use them as much as we do.
a
image.png
We have one big source root for everything than pants plugins, so that's not a big issue.
g
Oh, wait. https://www.pantsbuild.org/dev/reference/targets/code_quality_tool is exactly what you want, isn't it?
👀 1
I've never used it, but seems to solve exactly "give me all python files and run a pex against them"
a
That... looks like exactly what we want!
Alright, I'll give that a whirl tomorrow. Thanks! This was a very pleasant and productive whinge 😂
@witty-furniture-6665 check this out https://github.com/pantsbuild/pants/pull/20135 🤔
👀 1
12 Views
Open in Slack
PreviousNext
Powered by