bazel run should not inherit RUNFILES_DIR from OS

[linzhp]

Description of the bug:

Runfile libraries such as github.com/bazelbuild/rules_go/go/runfiles relies on the environment variables RUNFILES_DIR and RUNFILES_MANIFEST_FILE to work correctly. These two variables are set by Bazel during bazel run. However, if they are set in OS, Bazel would inherit them and not set them anymore, leading to machine dependent behaviors.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Create a repo like this:

-- WORKSPACE --
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "56d8c5a5c91e1af73eca71a6fab2ced959b67c86d12ba37feedb0a2dfea441a6",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.37.0/rules_go-v0.37.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.37.0/rules_go-v0.37.0.zip",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")

go_rules_dependencies()

go_register_toolchains(version = "1.19.3")
-- BUILD.bazel --
load("@io_bazel_rules_go//go:def.bzl", "go_binary")

go_binary(
    name = "runfiles",
    srcs = ["main.go"],
    data = ["@go_sdk//:tools"],
    deps = ["@io_bazel_rules_go//go/runfiles"],
)
-- main.go --
package main

import (
        "fmt"
        "log"

        "github.com/bazelbuild/rules_go/go/runfiles"
)

func main() {
        loc, err := runfiles.Rlocation("go_sdk/bin/gofmt")
        if err != nil {
                log.Fatal(err)
        }
        fmt.Println(loc)
}

2. Run:

RUNFILES_DIR=/tmp bazel run //:runfiles

It outputs /tmp/go_sdk/bin/gofmt, but Bazel should ignore RUNFILES_DIR=/tmp, and output something like /private/var/tmp/_bazel_zplin/a20570cf42c983bd18597126a6b3c06e/external/go_sdk/bin/gofmt instead.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 6.0.0-homebrew

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

The list of variables potentially affecting runfiles libraries further includes JAVA_RUNFILES, PYTHON_RUNFILES and RUNFILES_MANIFEST_ONLY.

@meteorcloudy @Wyverald What do you think, could bazel run drop these variables from the environment? Not doing so potentially breaks the runfiles library "promise" to "just work" with bazel run.

[meteorcloudy]

In general, I think it makes sense, but I wonder under what circumstances, users would set those env vars before running bazel run? And what if the user just runs the binary directly, it could still be a problem, right?

[fmeum]

I'll defer to @linzhp for the first question.

Running a binary directly already has some notable differences from running it via bazel run, e.g. args an env aren't honored. I don't think users would expect everything to just work if they do that, but they should probably be able to assume that bazel run makes it so.

[linzhp]

users would set those env vars before running bazel run?

This is just a way to reproduce the issue. In the real scenario, they set RUNFILES_DIR in their $HOME/.zshrc file when they were debugging something else in the past and forgot to remove it. When we enable Python Gazelle extension, which uses the runfiles library to locate Python parser, they found Gazelle no longer work for them.

And what if the user just runs the binary directly, it could still be a problem, right?
In such scenario, it's users responsibility to set RUNFILES_DIR correctly, or pass the files via command line arguments.

[meteorcloudy]

I see, thanks for the context! I'm happy to review a PR to address this issue ;)

[iancha1992]

A fix for this issue has been included in Bazel 6.4.0 RC2. Please test out the release candidate and report any issues as soon as possible. Thanks!