feat(monty): unlock the Python stdlib in molds and harden the runtime - #37
Open
pytgaen wants to merge 6 commits into
Open
feat(monty): unlock the Python stdlib in molds and harden the runtime#37pytgaen wants to merge 6 commits into
pytgaen wants to merge 6 commits into
Conversation
- fix(pipeline): enforce a chain-wide duration budget and cap dynamic step injection - fix(json): preserve exact integers through the complete native JSON u64 range - perf(ndjson): stream identity NDJSON to pretty and compact JSON - fix(output): install streamed files safely while preserving existing file semantics - fix(shape): support multi-input raw pass-through with -O - fix(sandbox): reject overflowing duration values - fix(http): normalize MIME detection and reject error statuses before body reads - fix(library): return an error for empty pipeline configurations - fix(runtime): bound regex, template, and HTTP client caches - fix(install): require exact SHA-256 manifests on POSIX and Windows - ci(install): exercise fail-closed installers and a Windows binary smoke test - chore(deps): refresh compatible direct and transitive dependencies - docs: align runtime, security, formats, comparison, and platform guidance - test: expand correctness, file-safety, installer, and performance coverage
Replace the Monty Git pin with the published monty and monty-types crates. Adapt boundary imports, compile options, and OS-call resumption to the 0.0.19 API. Refresh compatible dependencies while retaining the jiter security patch and get-size2 compatibility pin. Update build metadata and internal dependency documentation.
…n molds Molds can now `import collections` (Counter, defaultdict, deque, namedtuple), `import itertools` (count, repeat, pairwise, compress, islice, chain, cycle) and `import dataclasses` for a native @DataClass defined in the mold itself. Function decorators and plain classes work too — the latter already did, despite what the docs claimed. Monty 0.0.20 is where all of this lands, and where the host API breaks: LimitedTracker and NoLimitTracker are gone, ResourceTracker went from trait to concrete struct, the generic parameter it threaded through MontyRepl / ReplProgress / RunProgress disappeared with it, and ResourceLimits::new() was replaced by its Default impl. 0.0.21 changes nothing fimod links against — monty/src and monty-types/src are byte-identical to 0.0.20 — so go there directly. The part the compiler cannot catch is that 0.0.20 also moved max_memory enforcement out of the interpreter's own accounting and into two globals that only a charging allocator writes. fimod installs mimalloc, so those counters would never move and the limit would silently stop applying: a mold accumulating 3M dicts under a 50MB cap was measured reaching 1.7GB. Rather than adopt monty-alloc, which forwards to System and costs ~20% on every invocation, keep mimalloc and charge the counters around it in mem_limit.rs. unsafe_code stays denied everywhere except that module. The regression would have shipped green, because nothing covered the enforcement itself — only config parsing. The new sandbox test closes that: it fails when the allocator is reverted to bare mimalloc. Dropping the jiter git patch is now possible as its comment anticipated; 0.0.21 resolves jiter 0.16.0 from the registry, leaving no git source in the lockfile.
…x to 0.19 serde-saphyr 0.0.29 -> 1.1.0 and fancy-regex 0.18 -> 0.19 are the only root dependencies left behind after refreshing the lockfile; every other crate in Dependabot's pending batch is already at or above the requested version. fancy-regex 0.19 makes Captures generic over its input type (Captures<'t, S: Input + ?Sized>) so it can back both str and [u8] matching. fimod only ever matches against str, so the two helper signatures in src/regex.rs are pinned to Captures<'_, str>. get-size2 stays pinned at 0.10.1: 0.10.2 already moves to compact_str 0.10 while Ruff 0.0.3 is still on 0.9, which puts two CompactString types in the graph and breaks Ruff's derive(GetSize). The comment now records that boundary and the condition to lift it.
The draft was written for 0.9.1, before feat(monty) landed on the branch and pushed the bump to minor. Retitle it and fold in what it never covered: the Monty v0.0.21 upgrade and the standard-library modules it unlocks in molds, the allocator work that keeps max_memory enforced, the test that closes the enforcement gap, and today's dependency batch. The old Housekeeping line credited the previous batch with a serde-saphyr bump, which now contradicts the 1.1 upgrade; the dependency entries are rewritten as one coherent set.
The incus branch of container_start() provisions its container; the docker branch provisioned nothing, and ubuntu:24.04 ships without a trust store. reqwest could not build its HTTPS client at all, so both remote-mold tests failed under docker regardless of the binary under test. The failure surfaced as "Mold not found in any configured registry", which reads like a broken build rather than a missing CA bundle.
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
1 participant
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.
collections,itertools, anddataclassesimportable from molds alongside function decorators and user-defined classesmax_durationto the complete chain, including dynamically injected steps, instead of resetting the timer for every Monty executionpipeline.insert_next()/pipeline.append()growth after 1,024 injected steps with an explicit errori64::MINthroughu64::MAXas numeric JSON values when converting to and from Monty, including direct serializers--output-format raw -O, using each input filename as the destinationmax_memoryenforced after Monty v0.0.20 moved memory accounting into allocator globals, by charging those counters around mimalloc insrc/mem_limit.rstext/*response bodies textualrun_pipeline()receives a configuration with no mold or expression stepmax_memory, closing the gap that let the enforcement regression build greenmonty/monty-typescrates and drop thejiterGit patchserde-saphyrto 1.1 andfancy-regexto 0.19, absorbing the pending Dependabot batchca-certificatesin the docker e2e container, whichubuntu:24.04omits — reqwest could not build its HTTPS client, so both remote-mold tests failed under docker regardless of the binary under test