incompatible_bzl_disallow_load_after_statement: Require load() be at the top of bzl files

[c-parsons]

This is a tracking issue for offering a migration solution for
--incompatible_bzl_disallow_load_after_statement

This flag would enforce that bzl files have load() statements listed first.

[ittaiz]

should the title change? It talks ab out BUILD files but the content seems to be about bzl files?
Also is this a constraint on the WORKSPACE file as well?

[c-parsons]

Apologies, yes, this is about bzl files. I've changed the title.
This would not be a constraint on WORKSPACE files.

[laurentlb]

We should do the same for BUILD files (we can track it in a separate issue). But not for WORKSPACE files, because they are evaluated in a relatively different way: previous statements affect the semantics of load.

[dslomov]

What is missing for migration: migration docs, length of migration window. After these are done, please add "migration-ready" label.

[ittaiz]

I think there may be a gap here- bzl files which are used only in the WORKSPACE file (directly and indirectly) need to be able to have load statement in the middle (like the WORKSPACE itself).
Use-case is the deps pattern of manual recursive workspaces

[laurentlb]

cc @aehlig

[aehlig]

cc @aehlig

As mentioned in a related discussion, 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.

[laurentlb]

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.

[ittaiz]

+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> .