that line creates a BuildConfiguration, which reso...
# development
w
that line creates a BuildConfiguration, which resolves plugins (but doesn't load them), and then the call to
setup
actually loads backends.
...but by that point we already have bootstrap options, so I suppose that we could initialize logging sooner.
...oh. doh. i think that you can basically do something like this:
Copy code
diff --git a/src/python/pants/bin/local_pants_<http://runner.py|runner.py> b/src/python/pants/bin/local_pants_<http://runner.py|runner.py>
index 9021d2d..15d2241 100644
--- a/src/python/pants/bin/local_pants_<http://runner.py|runner.py>
+++ b/src/python/pants/bin/local_pants_<http://runner.py|runner.py>
@@ -175,11 +175,11 @@ class LocalPantsRunner(ExceptionSink.AccessGlobalExiterMixin):
         """
         build_root = get_buildroot()
 
-        options, build_config = LocalPantsRunner.parse_options(options_bootstrapper)
-        global_options = options.for_global_scope()
+        global_options = options_bootstrapper.get_bootstrap_options().for_global_scope()
         # This works as expected due to the encapsulated_logger in DaemonPantsRunner and
         # we don't have to gate logging setup anymore.
         setup_logging_from_options(global_options)
+        options, build_config = LocalPantsRunner.parse_options(options_bootstrapper)
 
         # Option values are usually computed lazily on demand,
         # but command line options are eagerly computed for validation.
@hundreds-father-404: ^
h
thatโ€™s what I just figured out ๐Ÿ˜„ thanks!
w
heh. nice.
h
it worked! yay!
๐Ÿ‘ 1
w
this all should be clearer.
๐Ÿ‘ 1
h
actually yeah this is the stuff that only got merged today, so definitley make sure you're on the latest master when you're looking at this code
๐Ÿ‘ 1
although now that I'm looking at it again, I think the changes I remember making to LocalPantsRunner were removed in theprocess of getting that PR to pass CI