Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Expose target wildcard matching to Starlark #7763
Description of the feature request:
Please expose Bazel's capability of matching target labels against wildcards to Starlark. Given a list of target patterns and a list of targets, return the list of all targets that match any of the given patterns. Patterns should have the same feature set as patterns allowed on the command line. E.g. specific
Feature requests: what underlying problem are you trying to solve with this feature?
The use-case that prompts this feature request comes from
See below for some background and motivation.
Currently, we re-implement a subset of Bazel's target pattern matching in Starlark to enable this interface. This is duplicated effort that should not be necessary. And we would prefer to offer our users Bazel's full pattern capabilities.
Note, that we cannot use
Background on Haskell REPL
With Haskell's REPL there is an important distinction between loading a target by source or as binary. If you load by source, this allows you to modify the source file, instruct the REPL to reload sources, and observe your code changes in the REPL right away, allowing for a fast feedback loop. Loading by binary instead means that code changes only become visible if you close the REPL, rebuild the binaries, and reopen the REPL. In practice this is too slow for productive development.
However, some targets should not be loaded from source, but instead as binary. Reasons for this could be that they require compiler flags that are incompatible with other modules, or you're not interested in modifying their source and want the speed benefit of loading them as binary.
What operating system are you running Bazel on?
What's the output of
Can you detail which capabilities you'd like?
In the example:
from_source = [ "//package-a/...", ],
It seems like you only need to check a prefix:
@laurentlb At the moment our own implementation supports absolute labels in the local workspace, e.g.
Note, I'm not asking to add additional pattern matching capabilities to Bazel. Instead, my point is that this kind of pattern matching is something that Bazel already implements internally. It would be better if rules could just use Bazel's builtin pattern matching to make sure that the set of supported patterns is identical to what users expect from their experience with Bazel itself, and also so that the pattern matching stays in sync if it's ever extended in Bazel.
This would be useful for my use case as well. I want to create a test rule to verify that every file in some set of files in the source tree is depended on, at least transitively, by some test rule, in order to enforce that developers don't forget to update BUILD files when appropriate.
I can do this from the command line easily enough with