https://pantsbuild.org/ logo
Join Slack
Powered by
Why does the "Resolving plugins" work appear to ha...
# general
h
Why does the "Resolving plugins" work appear to happen twice on pantsd startup?
Copy code
statler-2:[~/src/pants][main]$ ./pants test src/python/pants/base/::
12:50:44.89 [INFO] Starting: Resolving plugins: hdrhistogram, toolchain.pants.plugin==0.17.0
12:50:49.77 [INFO] Completed: Resolving plugins: hdrhistogram, toolchain.pants.plugin==0.17.0
12:50:51.96 [INFO] Initializing scheduler...
12:50:53.10 [INFO] Scheduler initialized.
12:50:53.12 [INFO] Starting: Resolving plugins: hdrhistogram, toolchain.pants.plugin==0.17.0
12:50:56.64 [INFO] Completed: Resolving plugins: hdrhistogram, toolchain.pants.plugin==0.17.0
đź‘€ 1
w
unknown… but it hasn’t always. if you have time to bisect, that would be helpful
h
Will do
e
Pre-emption seems naively semi-obvious.
w
i think that the fact that this is pre/post-“initializing scheduler” rules that out.
… but, i could maybe have suggested 
-ldebug
before bisection
h
I'll dig a little deeper
Is this related to bootstrapping? We do this once when we create the bootstrap options and once when we create the full options?
Just hypothesizing
w
the “bootstrap” scheduler which is used to resolve plugins does not itself have any plugins installed. so it shouldn’t be directly related. but 
-ldebug
or a bisect would be the easiest answer
h
Note that this only happens if I nuke lmdb_store, since the resolving process is cached between runs, I'm just wondering why it isn't used from cache on this second invocation
w
should also be able to use 
--no-local-cache
to repro
h
The input digests in each case are different in sha, but have the same size, will explore further
OK, so in the first invocation the 
PluginsRequest.constraints
contains the constraints from our lockfile, but in the second invocation it contains the union of that and the (transitive closure of) the plugin requirements
w
aha. so #14058 probably then
h
And that field is populated from 
tuple(<http://dist.as|dist.as>_requirement() for dist in working_set)
Very likely
I will verify
Confirmed
Before that commit only one resolve of plugins is attempted
It's not that the second one happens but comes from cache, it isn't requested
w
Ok. So the solution is probably to capture the working set before we resolve the first time to make it idempotent. Feel free to file and I can fix it tomorrow
h
That, or - why are we calling the resolver twice to begin with?
5 Views
Open in Slack
PreviousNext
Powered by