Try importing vendored libraries independently - #1076
Conversation
Debian/Ubuntu removes the vendored `yaml` library, but keeps `lexicon` and `fluidity`. Trying to import `lexicon` and `yaml` together will fail in this case: `yaml` is not available from the vendored directory and `lexicon` from the system. So try importing vendored libraries independently to allow replacing them individually.
8fad0a9 to
140c102
Compare
Mukller
left a comment
There was a problem hiding this comment.
Verified locally against upstream master and this exact head (140c102, Python 3.13) by blocking invoke.vendor.lexicon via a sys.meta_path hook and checking where each symbol resolves:
vendor lexicon unavailable:
master (before): Lexicon <- lexicon | StateMachine <- fluidity (system!)
^ vendor fluidity was perfectly healthy but never consulted,
because both imports share one try/except
branch (after): Lexicon <- lexicon | StateMachine <- invoke.vendor.fluidity
VERDICT: independent fallbacks
So on master, a broken or absent single vendored library silently downgrades its healthy sibling to the system copy too; this PR decouples that correctly. Import graph after the change is exactly the intended per-library cascade.
CI shows 2 failures — likely the usual matrix cells; nothing in the diff touches runtime behavior beyond import resolution.
One process note from my side: my first two local attempts accidentally ran against a different worktree state (I cloned a sibling fork for #1078 and reused it), which produced a false "coupled" result before I fetched your actual head ref. The verdict above is from the real 140c102 tree. Approving.
Debian/Ubuntu removes the vendored
yamllibary, but keepslexiconandfluidity. Trying to importlexiconandyamltogether will fail in this case:yamlis not available from the vendored directory andlexiconfrom the system.So try importing vendored libraries independently to allow replacing them individually.