Skip to content

Conversation

@bolinfest
Copy link
Collaborator

@bolinfest bolinfest commented Jan 8, 2026

To support Bazelification in #8875, this PR introduces a new find_resource! macro that we use in place of our existing logic in tests that looks for resources relative to the compile-time CARGO_MANIFEST_DIR env var.

To make this work, we plan to add the following to all rust_library() and rust_test() Bazel rules in the project:

rustc_env = {
    "BAZEL_PACKAGE": native.package_name(),
},

Our new find_resource! macro reads this value via option_env!("BAZEL_PACKAGE") so that the Bazel package of the code using find_resource! is injected into the code expanded from the macro. (If find_resource() were a function, then option_env!("BAZEL_PACKAGE") would always be codex-rs/utils/cargo-bin, which is not what we want.)

Note we only consider the BAZEL_PACKAGE value when the RUNFILES_DIR environment variable is set at runtime, indicating that the test is being run by Bazel. In this case, we have to concatenate the runtime RUNFILES_DIR with the compile-time BAZEL_PACKAGE value to build the path to the resource.

In testing this change, I discovered one funky edge case in codex-rs/exec-server/tests/common/lib.rs where we have to normalize (but not canonicalize!) the result from find_resource! because the path contains a common/.. component that does not exist on disk when the test is run under Bazel, so it must be semantically normalized using the path-absolutize crate before it is passed to dotslash fetch.

Because this new behavior may be non-obvious, this PR also updates AGENTS.md to make humans/Codex aware that this API is preferred.

Copy link
Contributor

@zbarsky-openai zbarsky-openai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice! very exciting

@bolinfest bolinfest merged commit f6b563e into main Jan 8, 2026
67 of 72 checks passed
@bolinfest bolinfest deleted the pr8879 branch January 8, 2026 02:06
@github-actions github-actions bot locked and limited conversation to collaborators Jan 8, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants