#692 reverse priority of path entries Pull request opened by dansola Bug: adjust_sys_path reverses FLYTE_SYS_PATH priority order Root cause

_run.py

builds

FLYTE_SYS_PATH

by iterating the local

sys.path

in order — highest-priority entries first.

adjust_sys_path

on the remote then processes those entries with

sys.path.insert(0, p)

one by one. Because each insert pushes previous entries down, the last entry in

FLYTE_SYS_PATH

ends up at position 0 (highest priority) which is the exact opposite of the local ordering.

cli/_common.py

appends the entrypoint file's parent directory to

sys.path

so the module can be imported. That directory is therefore the last entry captured into

FLYTE_SYS_PATH

. On the remote container it becomes the first entry in

sys.path

, giving it higher priority than the project root and causing any same-named modules inside that directory to shadow top-level packages. I think this bug occurs whenever you run flyte run with an entrypoint that's not at the project root. e.g.

flyte run workflows/foo.py

rather than

flyte run foo.py

. Fix Collect all

FLYTE_SYS_PATH

entries into a list first, then iterate in reverse before calling

sys.path.insert(0, p)

. This way the first entry in

FLYTE_SYS_PATH

(highest local priority) is inserted last and ends up at position 0 on the remote which is matching the local ordering.

entries = [p for p in os.environ.get(FLYTE_SYS_PATH, "").split(":") if p and p not in sys.path]
for p in reversed(entries):
    sys.path.insert(0, p)

flyteorg/flyte-sdk