https://pantsbuild.org/ logo
Powered by
h

happy-kitchen-89482

01/24/2022, 8:52 PM
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

witty-crayon-22786

01/24/2022, 8:56 PM
unknown… but it hasn’t always. if you have time to bisect, that would be helpful
h

happy-kitchen-89482

01/24/2022, 8:56 PM
Will do
e

enough-analyst-54434

01/24/2022, 9:20 PM
Pre-emption seems naively semi-obvious.
w

witty-crayon-22786

01/24/2022, 9:27 PM
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

happy-kitchen-89482

01/24/2022, 9:44 PM
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

witty-crayon-22786

01/24/2022, 11:27 PM
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

happy-kitchen-89482

01/24/2022, 11:27 PM
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

witty-crayon-22786

01/24/2022, 11:27 PM
should also be able to use 
--no-local-cache
to repro
h

happy-kitchen-89482

01/24/2022, 11:32 PM
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

witty-crayon-22786

01/24/2022, 11:55 PM
aha. so #14058 probably then
h

happy-kitchen-89482

01/24/2022, 11:55 PM
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

witty-crayon-22786

01/25/2022, 12:25 AM
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

happy-kitchen-89482

01/25/2022, 3:45 AM
That, or - why are we calling the resolver twice to begin with?
5 Views
Powered by