https://pantsbuild.org/ logo
Join Slack
Powered by
Are there any docs on writing plugins using the ca...
# plugins
a
Are there any docs on writing plugins using the call-by-name syntax yet?
w
At the moment, no - that's definitely stalled on my part during my yearly Sept/Oct "when will deliverable hell ever end"
Fortunately, the process is pretty simple, because it just involves calling the underlying function like you would normally, and the only quirk is the "implicitly" call
For some examples of it in use, you can check out the backends checked off here: https://github.com/pantsbuild/pants/issues/21065
a
So would I call this just like
Copy code
await get_git_worktree(GitWorktreeRequest(...), implicitly(MaybeGitBinary))
w
If you have all the parameters the function call requires, no need for implicitly Some examples of ports can be seen in these PRs: https://github.com/pantsbuild/pants/pulls?q=is%3Apr+%22%5BCall-by-name%5D%22+is%3Aclosed+ Specifically the ones that start "[Call-by-name]" that I wrote And here are the migration plugin's tests, so you can see other examples of when you need to/don't need to call it: https://github.com/pantsbuild/pants/blob/main/src/python/pants/goal/migrate_call_by_name_test.py https://github.com/pantsbuild/pants/blob/main/src/python/pants/goal/migrate_call_by_name_integration_test.py
In general, if you have all the explicit parameters you need to call a rule by name, there is no need for 
**implicitly
But, sometimes you have information which is ambiently pulled in by the rule engine. And then, in the strangest case, sometimes the whole call is wrapped - if there is the need to chain rule calls - these should be rare, as I think Benjy added one of the missing "Process" calls, which reduces the need for these types of calls
In your case specifically, if you have access to the git binary, you might have a call like:
Copy code
request = GitWorktreeRequest(...)
git_binary = ... #somehow you have access to the binary
result = await get_git_worktree(request, gitbinary) # Like any other call
The nuance happens when we don't have the git_binary
Copy code
request = GitWorktreeRequest(...)
result = await get_git_worktree(request, **implicitly()) # Implicitly tells Pants to figure this out
Generally, if you know the 
Get
syntax, then the mapping to call-by-name becomes slightly more obvious
h
Oh wow! Glad to see this one bringing some sanity to the plugins API 🙂
a
implicitly
seems to be trying to provide both the request and the 
maybe_git_binary
but when I remove the request it complains it doesn't have a rule for it - any ideas?
I might just write it as a 
Get
and use the migrate goal and see what it spits out.
Copy code
09:47:56.82 [ERROR] '/Users/nicholas.dellosa/Library/Caches/nce/6faa4322d1df41d032e4938795c6f2c262ab92bb642a9bac1101cb7d1631f9c1/bindings/venvs/2.21.0/lib/python3.9/site-packages/pants/backend/docker/subsystems/dockerfile_parser.py' is not in the subpath of '/Users/nicholas.dellosa/Projects/data-platform' OR one path is relative and the other is absolute.


Use --print-stacktrace for more error details and/or -ldebug for more logs. 
See <https://www.pantsbuild.org/2.21/docs/using-pants/troubleshooting-common-issues> for common issues.
Consider reaching out for help: <https://www.pantsbuild.org/community/getting-help>
😞
Copy code
await get_git_worktree(**implicitly(GitWorktreeRequest(".git")))
This worked though
w
This probably always works 
await get_git_worktree(**implicitly(GitWorktreeRequest(".git")))
Just less efficient. This is strange, assuming that GitWorktreeRequest is what get_git_worktree wants, then that should work
Something seems funky here - I'd have to test it out, but still without available time, unfortunately
result = await get_git_worktree(request, **implicitly())
-> whats the error?
a
Copy code
TypeError: get_git_worktree() got multiple values for argument 'git_worktree_request'
@wide-midnight-78598 Seems like it's trying to fill in both parameters, but there's no rule that generates a 
GitWorktreeRequest
from nothing since I get a rule graph error if I just do 
await get_git_worktree(**implicitly())
.
w
Hmm... This works for me:
Copy code
request = GitWorktreeRequest()
    result = await get_git_worktree(request, **implicitly())
I'm on an older version of pants though, maybe something changed
a
What about if you do 
await get_git_worktree(GitWorktreeRequest(".git"), **implicitly())
? I'm on pants 2.21
w
Just checking, are you running this on main?line pants Or an in-repo plugin?
a
in repo plugin
w
Ah, I'm not as sure if in-repo plugins work... I haven't tested any yet - as I was going through pants first
a
Makes sense, want me to open a bug issue?
w
👍
I knew i tracked something like this sorta - maybe add on to this? the migration call won't work on in-repo without this
a
When writing unit tests for plugins using the call-by-name syntax, what should the 
QueryRule
passed to the rule runner look like? Getting the following rule graph error with 
QueryRule(MaybeGitWorktree, [GitWorktreeRequest])
Copy code
No source of dependency pants.vcs.git.get_git_worktree(, **implicitly(GitWorktreeRequest)) -> MaybeGitWorktree for @rule(plugins.docker_image_tagger.plugin:31:tag_with_git_meta(GitMetaDockerImageTagsRequest, DockerImageTaggerSubsystem) -> DockerImageTags, gets=[pants.vcs.git.get_git_worktree(, **implicitly(GitWorktreeRequest)) -> MaybeGitWorktree]). All potential sources were eliminated: []
8 Views
Open in Slack
PreviousNext
Powered by