fix(update): avoid refreshing inactive lazy backends - #27878
Conversation
alt-glitch
added
type/bug
|
Thanks for the focused fix. I verified the premise against current main, and this still looks like a real Current main has Suggested changes
I also checked staleness mechanics: Automated hermes-sweeper review. |
teknium1
left a comment
teknium1
left a comment
There was a problem hiding this comment.
Thanks for the focused regression fix. The premise remains valid on current main: tools/lazy_deps.py:870 treats any installed spec as evidence that a lazy feature is active, while platform.matrix includes shared helper dependencies at tools/lazy_deps.py:175-183. hermes update consumes that result at hermes_cli/main.py:7636-7648.
Suggested changes
- Please add a short comment near the
LAZY_DEPSmap header that the first spec in a multi-package tuple is the active-detection anchor. The updatedactive_features()docstring explains the rule, but the map is where future tuple reorderings would otherwise accidentally change it.
Automated hermes-sweeper review.
| refresh pass when pins move in :data:`LAZY_DEPS`. | ||
| """ | ||
| active = [] | ||
| for feature, specs in LAZY_DEPS.items(): |
There was a problem hiding this comment.
Please also document near the LAZY_DEPS map that the first spec is the active-detection anchor. This predicate makes tuple ordering behavioral, and the map is the most likely place for a later edit to accidentally change that behavior.
teknium1
added
sweeper:risk-compatibility
teknium1
added
the
area/install-update
…atch uv.lock Generalizes the huggingface-hub lockstep test (#72320) to the whole LAZY_DEPS surface: any package exact-pinned in LAZY_DEPS that the core lock also resolves must pin the SAME version, so hermes update's lazy refresh can never churn or downgrade a shared package out from under its other consumers (#60783 class, #31817 class). Together with the anchor-based activation gate (previous commit, salvaged from #27878 by @paralegalia), this closes both halves of #44404: features no longer false-activate from shared transitives, and even a feature that legitimately activates cannot move a shared package away from the locked version.
…atch uv.lock Generalizes the huggingface-hub lockstep test (#72320) to the whole LAZY_DEPS surface: any package exact-pinned in LAZY_DEPS that the core lock also resolves must pin the SAME version, so hermes update's lazy refresh can never churn or downgrade a shared package out from under its other consumers (#60783 class, #31817 class). Together with the anchor-based activation gate (previous commit, salvaged from #27878 by @paralegalia), this closes both halves of #44404: features no longer false-activate from shared transitives, and even a feature that legitimately activates cannot move a shared package away from the locked version.
|
Salvaged and merged in #72361 with your authorship preserved via cherry-pick (plus a class-wide LAZY_DEPS↔uv.lock lockstep invariant on top) — you were the earliest submitter of the anchor-gating fix. Thanks @paralegalia! |
…atch uv.lock Generalizes the huggingface-hub lockstep test (NousResearch#72320) to the whole LAZY_DEPS surface: any package exact-pinned in LAZY_DEPS that the core lock also resolves must pin the SAME version, so hermes update's lazy refresh can never churn or downgrade a shared package out from under its other consumers (NousResearch#60783 class, NousResearch#31817 class). Together with the anchor-based activation gate (previous commit, salvaged from NousResearch#27878 by @paralegalia), this closes both halves of NousResearch#44404: features no longer false-activate from shared transitives, and even a feature that legitimately activates cannot move a shared package away from the locked version.
4 participants
Summary
Test plan
from tools import lazy_deps
active = lazy_deps.active_features()
print('platform.matrix active?', 'platform.matrix' in active)
print('active_count', len(active))
PY