Add support for allow_single_file attribute to label_list and label_keyed_string_dict

[ash2k]

Description of the problem / feature request:

attr.label() supports allow_single_file attribute which is very convenient. For some reason attr.label_keyed_string_dict() and attr.label_list() do not although all of them support allow_files.

I think it would be useful and consistent to have support for allow_single_file attribute in the later two.

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

In some private codebase I use label_keyed_string_dict and I have to assert that the value resolves to a single file and fail() if not. Would be nice to remove this manual check.

[laurentlb]

What would that mean in a label_list? That every item in the list is a single file? At the end, you still end up with a collection of files. In that case, why would you want to allow ["a.cc", "b.cc", "c.cc"], but not a filegroup that returns the same information?

[ash2k]

I don't have a use case for this flag for label_list. I just mentioned it for completeness/consistency reasons. Maybe someone in their custom rule treats each item in that list differently somehow? e.g. "Each item goes into a file. Files are numbered with integers. 1 file per label in the list". I don't know :)

So, if it does not make sense, just ignore this case.

[laurentlb]

For label_keyed_string_dict, this looks like a reasonable feature request.

[ash2k]

I'd like to extend this feature request to also include the executable parameter. It is supported by label attribute type but not by label_keyed_string_dict and label_list. They all support providers and cfg but executable is missing.

I tried to use FilesToRunProvider in the providers parameter (thinking that maybe that way I can/am supposed to block non-executable labels) but Bazel does not like it and says name 'FilesToRunProvider' is not defined. I think this is either a bug (the symbol should be "exported" and be usable somehow) or this thing is not a provider actually. In that case the documentation should be fixed (but why is it called ...Provider then?). Am I missing something?

My use case: I'd like to be able to bazel run multiple targets and I wrote a rule to do that. It accepts a label_list but I cannot use the executable bit on it. So I have to check that each specified target is executable manually which is not ideal.

p.s. I'm wondering why not make all "label" attributes consistent and have the same set of "filtering" parameters?

[brandjon]

p.s. I'm wondering why not make all "label" attributes consistent and have the same set of "filtering" parameters?

I agree we could be more consistent here. But there's a cost to changing the API, and I wouldn't want to make it without a clearer sense of exactly what we're aiming for. Leaving this issue open but not prioritized.

[jkrems]

FWIW, I also just ran into this with a label_keyed_string_dict where I wanted to map single files to a string each (in my case: HTTP route patterns).

[seh]

I wrote this function after inspecting the keys (pointing at files) that wound up in my label_keyed_string_dict:

def _file_from_label_keyed_string_dict_key(k):
    # NB: The Targets in a label_keyed_string_dict attribute have the key's
    # source file in a depset, as opposed being represented directly as in a
    # label_list attribute.
    files = k.files.to_list()
    if len(files) != 1:
        fail(msg = "Unexpected number of files in target {}: {}".format(k, len(files)))
    return files[0]

I have no idea whether I can count on this working in the future.

[thesayyn]

I don't see why this isn't P2. Since other attr types have this already, label_keyed_string_dict should have it too.