Support for @repo//... targets in acls logic about rules_android HOT 5 OPEN

@timpeut

from rules_android.

Hi Mauricio,

What do you think about changing the acls.bzl behavior to return True for all external repos? I'm not sure what really can/should be done for external ACL support, since technically users can name external repos anything they want, so there's essentially an unbounded set of possible targets to consider.

from rules_android.

Hi Mauricio,

What do you think about changing the acls.bzl behavior to return True for all external repos? I'm not sure what really can/should be done for external ACL support, since technically users can name external repos anything they want, so there's essentially an unbounded set of possible targets to consider.

Yeah I think that works, most of this acls only make sense in the context of google. Internally we are already defaulting all acls to a sensible default.

from rules_android.

Internally we are already defaulting all acls to a sensible default.

I suspect that most power users will have to do something similar, either with a soft fork of the codebase or a patch command to http_archive() (or the bzlmod equivalent), at least with the current way that ACLs are implemented. The only alternative I can think of where we can expose these ACL settings to users with zero code modifications is by proliferating hundreds (?) of constraints, which is pretty ugly.

from rules_android.

@mauriciogg I landed the fix that defaults ACLs to true. If this resolves things on your end I think we can close this issue.

from rules_android.