Repository navigation
chore(bridge): repin to pyMzLib v0.5.0 - #33
Merged
Merged
Conversation
Regenerated from the SHA256SUMS asset by scripts/regen-bridge-pins.R. Opened by bridge-watch.yml.
trishorts
added a commit
that referenced
this pull request
Oct 21, 2026
The 0.5.0 bridge main pins (#33) is built from mzLib 1.0.595 (d10017ce), which carries 1.0.594. Ports pyMzLib #79 (d108ea5). - Re-vendored from pyMzLib main byte for byte: the three convert recordings, readers_formats.json and readers_results_psmtsv.json. Every other shared fixture, the stats recordings included, already matches. - ProForma names UniProt modifications by UNIMOD accession (mzLib #1403): ?peptidoform_convert and the peptidoforms article lose "ProForma does not resolve UniProt modifications" and say what still differs (a modification no list knows is written back by name). The tests pin UNIMOD:34, five caveats, not six, and ProForma's outputs equal Unimod's on BottomUpExample. - DIA-NN 2.x report.parquet (DiaNnReportParquet, mzLib #1384): 39 formats, 5 quantifiable. ?readers_formats, ?readers_read_results and the FlashLFQ article name it, with its column-based dispatch, retention time in minutes, and the empty absent_fields. Tests move 38 -> 39 and 4 -> 5. - NEWS: an mzLib 1.0.595 section, and the release projects 1.0.595. Live against the 0.5.0 bridge this clears three of the four failures. The fourth, the stats fit that must equal stats_fit_limma.json bit for bit, is mzLib's: the recording predates 1.0.594 (#1398) and pyMzLib compares it to 1e-9, so it was never re-recorded. The test is left as it is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nbjsh1WCYFwbbG5CPbRygW
trishorts
added a commit
that referenced
this pull request
Oct 21, 2026
…ib 0.5.0 does (#34) * feat: leave the defaults to mzLib, as pyMzLib 0.5.0 does Ports pyMzLib #82, #83, #84 and #85 onto the 0.5.0 bridge main now pins (#33). The rule: an argument the caller leaves out is not sent, and mzLib's default applies. mzLibR keeps no copy of one. - peptidoform_fragments(): protease, dissociation, missed_cleavages, min_length, max_length, max_modifications, max_isoforms and terminus default to NULL and go on the wire only when given, so DigestionParams' defaults apply, and for dissociation the bridge's HCD until mzLib#1488. The old "trypsin|P" and ETD were mzLibR's own; protease = "trypsin|P", dissociation = "ETD" gives the old answer. Given values are checked as before; max_length below min_length is refused only when both are given. A digest stamps min_length, max_length and missed_cleavages NA when left to mzLib (the wire does not echo them) and prints them as mzLib's default. Help counts re-measured at d10017ce: albumin 310 peptidoforms / 202 sequences (trypsin|P 195), 257 at min_length 1; H3.1 49 of 96, 2,419 and 6,580, 8,644 of 12,808 at the cap. - pride_list_files(), pride_search(): page_size defaults to NULL and is sent only when given. PXD000001: 9 of 14 files on 2026-10-21. - stats_fit(): the help no longer says the bridge's spline default is 4. mzLibR already sent no --spline-basis unless asked. - Specs re-synced from bridge 2788702 (adds modifications.resolve, not projected) and help pages re-rendered; scripts/pymzlib-ref moves to pyMzLib v0.5.0 (2f9fc05). - peptidoform_P02768.json and _small.json re-vendored byte for byte (trypsin, HCD). The ETD traps now test peptidoform_P02768_etd_small.json, mzLibR's own recording from the 0.5.0 bridge of the old call spelled out; its two peptides are identical to the recording it replaces. - The replay bridge ports RECORDED_WITH (#83): a call without --max-mods is not answered from the max-mods 1 albumin digest. - README, the peptidoforms article, NEWS and docs/test-parity.md follow. README's "ETD returns a y series" trap, fixed by mzLib #1114, is gone. Fail on origin/main: a default call sends only the accession; a default call replays the default recording end to end; given options are sent alone; max_length is sent only when given; the RECORDED_WITH rule; the print of settings left to mzLib; a page size left out is not sent. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nbjsh1WCYFwbbG5CPbRygW * feat: project mzLib 1.0.595, as pyMzLib #79 does The 0.5.0 bridge main pins (#33) is built from mzLib 1.0.595 (d10017ce), which carries 1.0.594. Ports pyMzLib #79 (d108ea5). - Re-vendored from pyMzLib main byte for byte: the three convert recordings, readers_formats.json and readers_results_psmtsv.json. Every other shared fixture, the stats recordings included, already matches. - ProForma names UniProt modifications by UNIMOD accession (mzLib #1403): ?peptidoform_convert and the peptidoforms article lose "ProForma does not resolve UniProt modifications" and say what still differs (a modification no list knows is written back by name). The tests pin UNIMOD:34, five caveats, not six, and ProForma's outputs equal Unimod's on BottomUpExample. - DIA-NN 2.x report.parquet (DiaNnReportParquet, mzLib #1384): 39 formats, 5 quantifiable. ?readers_formats, ?readers_read_results and the FlashLFQ article name it, with its column-based dispatch, retention time in minutes, and the empty absent_fields. Tests move 38 -> 39 and 4 -> 5. - NEWS: an mzLib 1.0.595 section, and the release projects 1.0.595. Live against the 0.5.0 bridge this clears three of the four failures. The fourth, the stats fit that must equal stats_fit_limma.json bit for bit, is mzLib's: the recording predates 1.0.594 (#1398) and pyMzLib compares it to 1e-9, so it was never re-recorded. The test is left as it is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nbjsh1WCYFwbbG5CPbRygW * test(stats): thread counts bit for bit, the recording to 1e-9 The live limma test compared a threads = -1 fit with stats_fit_limma.json bit for bit, under the label "the same at any thread count". The recording was made at mzLib 1.0.593, and 1.0.595's prior arithmetic differs from it by about 1e-14 relative (prior df 4.531798758719062 against 4.5317987587192796; estimates identical), so the test failed on the 0.5.0 bridge for a reason that is not a thread-count difference. It now checks each thing it claims, and keeps every guarantee: - bit for bit: a live threads = -1 fit against a live threads = 1 fit, t and bh_adjusted; - against the recording: t and bh_adjusted to 1e-9 relative, the tolerance pyMzLib's live check uses, so drift between the recorded bridge and the live one is still caught; - against limma's published output: unchanged, 1e-8. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nbjsh1WCYFwbbG5CPbRygW * docs(specs): re-sync at bridge 22638d4 and regenerate the help pages One new open question in peptidoform.fragments (the envelope does not echo missed cleavages or the length window); the rest is source stamps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nbjsh1WCYFwbbG5CPbRygW * docs: regenerate name-parity for the bridge 22638d4 specs Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nbjsh1WCYFwbbG5CPbRygW --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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.
pyMzLib published v0.5.0. This repins
R/install-bridge.Rfrom0.4.0to0.5.0, with all four SHA-256 digests regenerated byscripts/regen-bridge-pins.Rfrom that release'sSHA256SUMSasset.What to check before merging
The digests come from the release manifest, so they are right by construction if
the manifest is. What CI cannot tell you is whether the new bridge changes any
value mzLib reports — the live canaries exercise the wire contract, not the
numbers crossing it. If the pyMzLib release notes mention a reader or a unit
changing, look for a caveat in this package that has become wrong.
Under
BRIDGE-MAINTAIN-PARITY, a bridge bump that retires a caveat retires itin pyMzLib, mzLibRust and mzLibR as one unit of work.
0.4.0Regenerating the pins updates the code, not prose. Each of these is a sentence a
human needs to reword — preferably to point at where the value lives rather than
to restate it, since nothing regenerates or tests a version number in prose.
Opened by
.github/workflows/bridge-watch.yml.