Getting a runfiles directory with runfiles.Rlocation instead of bazel.Runfile about rules_go HOT 3 OPEN

Instead of __main__, you can also use the name of your main workspace or module (depending on whether you use Bzlmod).

Bazel's runfiles layout doesn't guarantee that the files under the logical runfiles directory __main__/some/directory all lie in the same physical directory. bazel.Runfiles used certain heuristics that may be non-hermetic and also don't work cross-platform.

The proper way to make your use case work would be to add an implementation of fs.FS to the runfiles instance. Help and contributions in this area would definitely be appreciated.

In the meantime, you can use a helper function that accepts both a runfiles path to a directory and the relative path of a file inside it and returns the actual path of the directory. This is what I'm currently using myself.

from rules_go.

The proper way to make your use case work would be to add an implementation of fs.FS to the runfiles instance. Help and contributions in this area would definitely be appreciated.

I'm happy to contribute something here, though I don't understand what it means to add an impl of fs.FS in this context. I see that *runfiles.Runfiles implements fs.FS, but under the hood, that's just calling r.Rlocation. I see the Directory implementation of path, which seems relevant, but I'm not sure how this all fits together.

Bazel's runfiles layout doesn't guarantee that the files under the logical runfiles directory main/some/directory all lie in the same physical directory.

That's odd, but I guess it doesn't matter as long as there are at least links in the right location. My use case here seems like a pretty standard happy path. I have a filegroup of some glob(['*.ext']) in a directory, and I pass that filegroup in as a data attribute to something that wants to look at all those *.ext, without referencing individual ones directly. Am I missing a more direct route to getting the path of the directory containing those files in Bazel's runfiles?

from rules_go.

I see that *runfiles.Runfiles implements fs.FS, but under the hood, that's just calling r.Rlocation.

Yep, that's exactly the problem: A fully featured fs.FS implementation would also implement https://pkg.go.dev/io/fs#ReadDirFS and provide logic that doesn't just go through r.Rlocation. For Directory, this would be straightforward, but for Manifest, the other supported runfiles mode, it would require more effort.

Am I missing a more direct route to getting the path of the directory containing those files in Bazel's runfiles?

No, there isn't, but it's not a simple omission. Since Bazel supports both directory-based and manifest-based runfiles and the latter are not realized on disk, there may not be a single filesystem path that contains all those files. The fs.FS abstraction would help here, as would using runfiles.New to explicitly force a Directory implementation if you know at you are only going to support Unix systems with --enable_runfiles.

from rules_go.