-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
attr.label / attr.label_list can't restrict to only accepting folders #6448
Comments
Using labels to reference directories is currently broken. Can you use |
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? |
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.
|
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>
.
|
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.
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 specifyattr.label
orattr.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 wasattr.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
orattr.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.The text was updated successfully, but these errors were encountered: