attr.label / attr.label_list can't restrict to only accepting folders

[dgoldstein0]

Description of the problem / feature request:

when declaring a rule, it's common practice to specify what file types are valid for particular fields, so bazel can enforce this. e.g.

my_special_c_lib = rule(
  impl = _my_impl,
  attr = {
    "srcs": attr.label_list(allow_files=[".c", ".h"],
    ...
  },
)

Bazel recently gained a type of File which represents a folder - which can be created via ctx.actions.declare_directory within a rule implementation, and then can be passed around in the files provider as another type of file. Unfortunately, as a folder isn't one file but rather many, it often need special treatment. It would be useful to be able to specify attr.label or attr.label_list that accept only folders, to have a few more static guarantees about how the rules are used. At the moment I can't find a way to do this. My guess was attr.label_list(allow_files=["/"]) but this does not have the desired effect.

Feature requests: what underlying problem are you trying to solve with this feature?

Being able to specify attr.label or attr.label_list that accept only folders would give more static guarantees about how the rules are used. It would be even nicer if a rule attr was able to "accept a folder of .js files" or something similar, though with the file extensions being dynamically generated in the execution phase, I could see how that would be harder to fit into the bazel model.

[laurentlb]

Using labels to reference directories is currently broken.
Doc: https://docs.bazel.build/versions/master/build-ref.html#label_directory
Related discussion: https://groups.google.com/d/msg/bazel-dev/vAf_k-OqFzY/BM5nGeq0BAAJ

Can you use glob to match the files instead?

[dgoldstein0]

no.

My issue is not that I'm using a filegroup. Rather, I have a rule that outputs a directory File in it's files provider; I would like bazel to verify that the label I pass has a files provider that only has directories.

It occurs to me, that I'm not actually sure whether bazel applies the allow_files option to validate the providers of each target in the label_list anyway... does it?

[laurentlb]

If it's inside your provider, you control what you put in it. There's no check when you create your provider, and someone could put a number instead of a target, for example.

When you declare your provider, I encourage you to document the provider and its fields (https://docs.bazel.build/versions/master/skylark/lib/globals.html#provider). If you're afraid that someone else will use your constructor and ignore the documentation, you can write your own function to check it.

allow_files is used for the default output (DefaultInfo provider). This is mostly useful when you expect a user to pass source files. If the label is another rule, you can use a provider to pass more structured information (use attr.label(providers = [...]) to ensure the target provides it).

[dgoldstein0]

hm, my other rule is just using a files provider to contain the folders. that seemed like the most straightforward implementation at the time - I didn't really see a need for a new provider otherwise.

…

On Wed, Oct 31, 2018 at 6:16 AM Laurent Le Brun ***@***.***> wrote: If it's inside your provider, you control what you put in it. There's no check when you create your provider, and someone could put a number instead of a target, for example. When you declare your provider, I encourage you to document the provider and its fields ( https://docs.bazel.build/versions/master/skylark/lib/globals.html#provider). If you're afraid that someone else will use your constructor and ignore the documentation, you can write your own function to check it. allow_files is used for the default output (DefaultInfo <https://docs.bazel.build/versions/master/skylark/lib/DefaultInfo.html> provider). This is mostly useful when you expect a user to pass source files. If the label is another rule, you can use a provider to pass more structured information (use attr.label(providers = [...]) to ensure the target provides it). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6448 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBnd3WCjci_0UN2Y_eyewG9-i637V9Hks5uqaKagaJpZM4Xvnct> .