https://pantsbuild.org/ logo
Join Slack
Powered by
The plugin I'm working on seems to be rather uniqu...
# plugins
h
The plugin I'm working on seems to be rather unique in a sense that I'm looking at the file tree structure instead of the content of the files The purpose is to compare the tree against a schema to make sure that there are no missing files (e.g. 
BUILD
, etc..) My main issue is that using 
LintFilesRequest
I only get the list of files that the target provided, but I don't have any way of knowing whether I'm at the root or on any branch I'm looking for a way to get the root path of the target, but I'm also open for any other suggestions for implementation or reference that might be useful 🙂
Right now I'm doing a silly check to "make sure" that I'm running from root with this condition
Copy code
if 'pants.toml' not in request.elements:
    exit_code = 1
But there must be a better way...
f
What do mean by "running from the root"?
Your linter could request a single partition for all of the files.
Your plugin could also request the 
PathGlobs -> Digest
conversion to look at files in the repository. That bypasses logic in the core fmt/lint rules but maybe that is okay?
There are linters which apply just to files (like the regex linter in 
src/python/pants/backend/project_info/regex_lint.py
)
But maybe the lint system is not the right way to express this sort of check?
h
Does your linter respond to the command line specs in any way? E.g., does 
pants mylinter path/to/dir1
behave differently than 
pants mylinter path/to/dir1
, or does it always act on the entire source tree?
h
To answer all your questions at once: 1. I would prefer for it to respond to the target selection, but right now since I don't have access to the "target root" (i.e. 
src/python
) I cannot know where I'm in the tree, hence I decided to always require running from root where 
pants.toml
is 2. I am using a single partition for all files, although I'm not sure that I see the benefit of creating a digest since all I care about is the file tree and it's already right there in 
request.elements
3. I was also asking myself if building a linter is the right way to do this... The reason I decided to go for it was because it'd make it so much easier to use instead of running a custom goal each time
h
Your goal can request the 
Specs
product, which is a representation of the target specs the user entered on the cmd line
h
That means I have to drop the idea of building a linter and use a goal instead?
f
There may be a way to still use a linter or have your plugin activated for the 
check
goal.
You could define a target intended to be used only once by the user, call it 
my_global_lint_checks
, and the user would put an instance of that target somewhere in there repository. For now, let's assume the root 
BUILD
file. You can then have your plugin register to be invoked for the 
check
goal for that target and it would trigger whenever someone does 
pants check ::
for example.
The plugin could have the configuration for the linting live on the target.
It sort of fits with why targets exist. You could potentially define different linting configurations for the same plugin based on there being different instances of this new target type.
If you want the user to avoid having to create an essentially empty target (e.g., 
my_global_lint_checks(name="global_linter")
) then your plugin can generate a "synthetic" target into the BUILD tree via the applicable Pants API (
SyntheticTargetsRequest
)
h
Your suggestion of "generating" targets sounds very appealing to me I'm failing to understand, though, why 
check
target is better than 
lint
Is there anything different between them, or is it just because my plugin sounds more fitting for this goal type?
f
If you aren't going to use any of the infrastructure of the 
lint
goal, then integrating with the 
check
goal might be easier since it just requires a 
FieldSet
subclass which can apply to your target.
h
I see Thanks, I'll look into that and report back 🙂
f
Compare 
CheckRequest
with 
LintTargetsRequest
👀 1
(Those are the "union" types which must be subclassed, respectively, to hook into 
check
and 
lint
)
But from a style POV, I agree 
lint
might make more sense, but sort of a judgment call.
9 Views
Open in Slack
PreviousNext
Powered by