Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
incompatible_bzl_disallow_load_after_statement: Require load() be at the top of bzl files #5815
changed the title
ncompatible_bzl_disallow_load_after_statement: Require load() be at the top of bzl files
Oct 31, 2018
As mentioned in a related discussion, I think restricting
In the context of
I agree the current situation feels unnatural, mainly because evaluation of WORKSPACE first splits the file. I think we don't split bzl files at all, even when they're loaded from a WORKSPACE file, right? So the main problem with incompatible_bzl_disallow_load_after_statement is that it prevents you from changing the semantics (but it doesn't affect current users)?
We can continue the discussion on the mailing-list, and see what we can do.
+100. As someone trying to maintain mutual complex definitions over 50 repositories these restrictions are cumbersome.…
On Wed, 9 Jan 2019 at 19:43 Klaus Aehlig ***@***.***> wrote: cc @aehlig <https://github.com/aehlig> As mentioned in a related discussion <https://groups.google.com/forum/#!topic/bazel-dev/GAmnpzGmuqM>, I think restricting load statements to the beginning of a file is fine in the context of BUILD files (i.e., loaded directly or indirectly from a BUILD file). BUILD files are evaluated at a point of time where all the sources of files are already well defined. In the context of WORKSPACE files, however, the situation is different as external repositories are still being defined (and hence new files to load from are being made available). In that context (i.e., when loaded directly or indirectly from the WORKSPACE file) I would suggest either allowing load statements everywhere, or at least support delaying the loading till the symbol is used for the first time. Currently, we are in the very unnatural situation that defining an external repository and then calling a Starlark function defined in one of its files is something that can be done top-level in the WORKSPACE file, but cannot be delegated to a macro. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF8Rrie15o99l50U_VxuLs_J8wk63ks5vBipIgaJpZM4V0v_f> .