glob in WORKSPACE files (and .bzl files loaded by same)

[shs96c]

Description of the feature request:

A glob() function for repository rules would be useful for repo rules.

Use cases include:

• Setting a dependency on e.g. a lockfile that may or may not exist with something like glob(“my.lockfile”, allow_empty=True). This would be useful for rules_jvm_external where a user has to know whether rules have been pinned or not when re-pinning.
• Providing a bunch of vendored dependencies needed by a repo rule (e.g. python wheels or jars we want to generate rules for).

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

Sometimes, it's just not possible or it's impractical to enumerate all the inputs while writing the entry in a WORKSPACE file. In addition, it requires a file to be present, and sometimes it's useful to check for the presence of the file itself.

What's the output of bazel info release?

3.4.1

[wt]

I would love to see this so that I could glob in diffs for a http_repository. That would be awesome.

[wt]

Oh, and I am using release 4.1.0rc4.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[fmeum]

Cc @Wyverald, this seems related to your proposal

[bcsgh]

Another use case would be to collect state that a generated repo rule depends on. In my case I'm wanting to expose the git tags on the current HEAD so that they can be passed as tags to oci_push.remote_tags. I can get the repository_rule to re-sync when HEAD changes by depending on @//:.git/HEAD but that only works for pre known paths.

FWIW; adding this would if anything make things more hermetic because repository_rule()s can already reach out to thing that are not listed. This would allow such cases to at least try to update correctly.

[Wyverald]

dupe of #20952 (which is fixed in 7.1.0; see cherry-pick PR #21435)

[bcsgh]

@Wyverald do you have a link to the relevant end user documentation? After reading through the referenced issue, I'm not clear on what was actually done there or what I should be using to solve this use case.

[Wyverald]

The new method repository_ctx.watch() allows you to watch for changes to one path (and methods such as repository_ctx.read() gain a new parameter that automatically causes them to start watching); path.readdir() now has a new parameter that allows you to watch for changes in the entries directly under a directory; and repository_ctx.watch_tree() allows you to watch for changes to everything under a directory tree.

These changes will be included in the 7.1.0 release notes (which are still being edited right now).