lberki

Looks promising! I didn't have time to make a proper pull request, but this change implementing the "split `RepoFileFunction` into two parts, one not requiring a repository mapping" approach: https://bazel-review.googlesource.com/c/bazel/+/261670...

https://github.com/bazelbuild/bazel/pull/24032 implements this feature, makes all test cases pass and is principled enough to be submittable. Let the review begin!

This is now fixed at HEAD: you can use the `ignore_directories()` directive in `REPO.bazel` to achieve the same effect as `.bazelignore`, except supporting glob-style wildcards. @meteorcloudy do you think I...

No can do, at least not with the urgency that P1 bugs need although I do agree that we should do this eventually.

With 78971a932bae9d788014df9b6235fb8242b59a77, creating a Starlark function that takes a `Runfiles` object and returns a `File` that is a runfiles tree containing those runfiles is very possible. In fact, I have...

It can't be a tree artifact because runfiles trees are materially different: tree artifacts have all the files within them and runfiles trees are only symlinks to other files that...

I won't take sides on what one should do with DefaultInfo (it's mostly orthogonal to whether the pertinent actions should be createable from Starlark), but what I'm hearing from both...

Do I understand correctly that arbitrary symlink trees are enough to kill `SpecialArtifact.FILESET` i.e. you don't need the tree artifact / runfiles tree hybrid functionality that you mentioned above?

My best educated guess is that `SpecialArtifactType.FILESET` and `SpecialArtifactType.RUNFILES` are mostly different now due to their history: there were implementations of two different legacy features inherited from the predecessor of...

Ideally, one would not make the distinction between tree artifacts and symlink trees either and instead be able to handle both symlinks and files in `TreeArtifact`s, but it's probably not...