Merged
Conversation
pingsutw
previously approved these changes
Feb 23, 2026
Member
pingsutw
left a comment
There was a problem hiding this comment.
LGTM, thanks, could you fix the lint errors
pingsutw
approved these changes
Feb 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug: adjust_sys_path reverses FLYTE_SYS_PATH priority order
Root cause
_run.pybuildsFLYTE_SYS_PATHby iterating the localsys.pathin order — highest-priority entries first.adjust_sys_pathon the remote then processes those entries withsys.path.insert(0, p)one by one. Because each insert pushes previous entries down, the last entry inFLYTE_SYS_PATHends up at position 0 (highest priority) which is the exact opposite of the local ordering.cli/_common.pyappends the entrypoint file's parent directory tosys.pathso the module can be imported. That directory is therefore the last entry captured intoFLYTE_SYS_PATH. On the remote container it becomes the first entry insys.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.pyrather thanflyte run foo.py.Fix
Collect all
FLYTE_SYS_PATHentries into a list first, then iterate in reverse before callingsys.path.insert(0, p). This way the first entry inFLYTE_SYS_PATH(highest local priority) is inserted last and ends up at position 0 on the remote which is matching the local ordering.