#3 fix: runfiles staging, copy_style, and pip auto-detection for macOS and Linux Pull request opened by hwuiwon ## What Fix several bugs preventing

flyte_deploy

,

flyte_build

, and

flyte_run

(remote) from working on macOS and Linux. Also simplify

flyte.bzl

by extracting all inline Python into a shared

flyte_runner.py

. ## Bug fixes 1.

copy_style=None

→

copy_style="all"

—

None

is undocumented and fragile 2. Remove

interactive_mode

— the SDK raises

NotImplementedError

if

True

, passing

None

is a no-op 3. Runfiles symlink breakage — Bazel runfiles are symlink trees pointing into the output base. Flyte's bundler calls

path.relative_to(cwd)

which fails since resolved symlinks are outside cwd. Fixed by staging runfiles into a real temp dir with

shutil.copytree(symlinks=False)

before calling

flyte.init()

4. Proto files invisible to bundler —

.venv.pth

entries point into the original symlink tree and get excluded. Fixed by parsing

.venv.pth

files and copying those directories into the staging root 5. Missing pip packages in remote container — extra Bazel pip deps aren't in the base Flyte image. Fixed by walking

importlib.metadata

to find non-flyte packages and injecting them via

image.with_pip_packages()

## Simplification Moved ~315 lines of Python embedded in Starlark

.format()

strings into

bazel/flyte_runner.py

. Each macro now generates a one-line wrapper and passes config via

py_binary

args

.

flyte.bzl

goes from 503 to ~200 lines with zero inline Python. Macro API is unchanged — no consumer BUILD changes needed. ## Changes •

MODULE.bazel

— add

aspect_rules_py

•

bazel/flyte_runner.py

(new) — shared entry point for run/deploy/build •

bazel/BUILD.bazel

— add

_flyte_runner_lib

py_library •

bazel/flyte.bzl

— replace code generation with CLI-arg-based dispatch flyteorg/bazel-example-v2