oss sync - #370
Merged
Merged
Conversation
|
imathur1
approved these changes
Jul 28, 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.
Regenerated from the internal monorepo with
evoscale sync-open-source, then formatted with this repo's ownpixi run lint-all.Provenance
ed19808f6a63fe5bbe7cfb5a49378c76f92403cf, which is internalmain@2a456e6366plus the one-line source fix described underpredicted_aligned_error.pybelow.3.3.0— no version bump, nopyproject.tomlorpixi.lockchange (lock was already up to date, so there is zero lock churn in this PR).Substantive vs formatter churn. The raw sync touched 71 files (+567/-314), but almost all of that was formatter churn: the internal repo and this repo have different ruff settings (this repo sets
skip-magic-trailing-comma/split-on-trailing-comma = false, so it collapses the exploded import and signature forms the internal formatter emits). After running this repo's own linter the diff is the 6 files below, +25/-15 — all real content. Nothing here is reformatting.Changes
esm/utils/msa/msa.py(+msa_test.py)from_a3m. The oldassert len(seq) == len(entries[0].sequence)fired incorrectly whenever insertions were kept — which is the default (remove_insertions=False) — because preserved insertions make rows different lengths. Replaced with a match-column-count check that raisesValueError, plus a regression test. Docstring/comment that still claimedremove_insertions=Truewas the default are corrected.esm/sdk/forge.pypotential_sequence_of_concernnow defaults toFalseonSequenceStructureForgeInferenceClient.inverse_foldand.async_inverse_fold, so it is no longer a required positional argument. 2 lines.esm/utils/structure/predicted_aligned_error.pycompute_tmnow uses@torch.no_grad()rather than the bare@torch.no_grad. Runtime behaviour is identical (no_grad.__new__already routes the bare form throughcls()(func)), but the called form is what the other 7no_graddecorators in the package use, and type checkers no longer infer the decorated function as ano_gradinstance. 1 line.esm/models/vqvae.py# ty:ignore[unknown-argument]suppressions at thecompute_tmcall site, which the line above makes unnecessary. No code change._assets/esmfold2_folding.pngNet effect on type-checking: this removes 3
ty:ignorecomments rather than adding any. Those 3 had been added directly in this repo and were therefore reverted by every sync; fixing the decorator upstream makes the sync idempotent here.Verification
All run against this synced tree in this repo's own pixi env, with no monorepo on
sys.path(asserted:monorepo on sys.path: False).Plus a targeted script asserting, for the three non-MSA files: both
inverse_foldsignatures default toFalse;compute_tmreturnsrequires_grad=Falsewith finite pTM in[0,1]and is deterministic across the kwargs call pathvqvaeuses;StructureTokenDecoderimports and retains itscompute_tmcall with noty:ignoreleft.Honest limitations
typre-commit hook reports 228error[unresolved-import]fortorch/numpy. That is the hook failing to locate the pixi env's site-packages, not a code issue —ty check --python .pixi/envs/devis clean, and CI'stest-precommitjob passes. It reported 3 real errors before the@torch.no_grad()change and 0 after.msa_test.pytogether withmolecular_complex_test.py/input_builder_test.py/prepare_input_test.pydeadlocks infutex_waitwith ~100 open pipes; this reproduces independently of this diff and I did not diagnose it. Verification above is therefore targeted per changed file, not a full-suite pass — I am not claiming the full suite green.tests/oss_pytests/client tests (need a Forge API token). Nothing in this diff touches the HF model code or the client transport.