https://pantsbuild.org/ logo
Join SlackCommunities
Powered by
:thread: Need some helps on understanding `Initial...
# general
g
🧵 Need some helps on understanding 
Initialization options changed: reinitializing scheduler...
After investigation, I’ve found diffs like:
Copy code
"root['name_to_api_type_info']['pants.core.goals.fix.Batch']['provider']": {'new_value': 'pants.backend.python.lint.autoflake', 'old_value': 'pants.backend.python.lint.black'
"root['name_to_api_type_info']['pants.core.goals.test.PartitionRequest']['provider']": {'new_value': 'pants.backend.shell', 'old_value': 'pants.core'
"root['name_to_api_type_info']['pants.core.goals.lint.Batch']['dependents'][0]": 'pants.backend.build_files.fmt.black',
However, I’m not sure how these changes are picked up by the pants, we do use different backend systems in our pants:
Copy code
backend_packages = [
  "pants.backend.plugin_development",
  "pants.backend.build_files.fmt.black",
  "pants.backend.docker",
  "pants.backend.docker.lint.hadolint",
  "pants.backend.python",
  "pants.backend.python.lint.autoflake",
  "pants.backend.python.lint.isort",
  "pants.backend.python.lint.black",
  "pants.backend.python.lint.flake8",
  "pants.backend.python.typecheck.mypy",
  "pants.backend.shell",
  "pants.backend.shell.lint.shfmt",
  "pants.backend.shell.lint.shellcheck",
  ...
But will these newly imported pkgs impact exiting init options dynamically? And is there anyway that we can lock the options during repeated pants goal run?
h
Initialization options changed: reinitializing scheduler...
means that Pants has detected a change to certain options since the pants daemon was last started
These are options that affect the daemon, so it must restart to pick up the new values
Is this in CI?
g
Yes, this is in CI, the config will be changed every time. Just want to be clear, we don’t have related changes regarding our pants BE systems, but when I looked into the ./pants help-all in our CI runs, these config got changed every time, which caused a 0 usage for the local cache.
h
When you say "the config will be changed every time" - you mean by design? What config changes are you applying?
g
Thanks, Benjy, here’s the investigation flow: • We’ve set up a specific task queue to run the command 
./pants dependents xxx
. • Ideally, on its second run, this command should fully use the existing cache for speed. • So, I ran this command twice in two builds, without making any changes. • Before each run, I reviewed all parameters with “./pants help-all” and noted the config details. • During the second run, I noticed the 
reinitializing scheduler
message indicating that the initialization options changed. • To understand this better, I compared the first and second run configurations using a JSON difference tool. ◦ Here’s the link showing the comparison.
Here’s the complete diff json.
differences.json
h
And which Pants version is this?
This might be a red herring, because name_to_api_type info shouldn't affect pantsd restarts
But it's still weird that it is changing between runs
@curved-television-6568 any thoughts?
g
Thanks Benjy, we are using 
2.17.0rc1
for our runs.
cc @rapid-bird-79300 I found this during my investigations, not sure whether it caused more invalidations for our local cache.
đź‘Ť 1
c
Feels like there’s some ordering issue with the loaded backend info for some reason (a missing sort perhaps). As this is used as input (
BuildConfiguration
) to options etc, I think it actually may play a role for bootstrap options etc being invalidated. Maybe. I can’t rule that out at least. Great catch if so, because I’ve had a feeling for quite some time that we get more scheduler invalidations than we ought to without having been able to pin-point why.
đź‘Ť 1
h
Yeah, I was wondering about sort order in the LazyDict thing
2 Views
Open in Slack
PreviousNext
Powered by