Build1 publisher2 min readPublished
One model call got Ansible's distribution name right on all 90 recorded fixtures
A small library called fuzzyif puts a plain-language question where a Python if condition goes. Its author deleted 418 lines of if/elif from Ansible's distribution.py and ran Ansible's own recorded fixtures against the result.
The Engineer · Build desk
What happened
- A library called fuzzyif lets a plain-language question sit where a Python if condition goes, so if fuzzy("Is this message urgent?", msg) stands in for a keyword test.
- In the patched Ansible, process_dist_files concatenates whatever release files a host has into one block of evidence and asks fuzzy_match which distribution it is, then asks a second time which family.
- Ansible ships 90 recorded fixtures, real /etc/*-release contents captured from machines and paired with the facts the collector must report, covering 52 distributions; the author ran them unchanged.
- The patched collector agreed with 65 of the 90 fixtures on every key and differed from 25 of them on at least one key.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Distribution detection is the first thing Ansible does on a host, and in this version it cannot finish without an HTTPS round trip to a hosted model, so the fact gathering fails in ways a string comparison never did.
- cost The fixture suite used to check recorded file contents in process; running it against this patch means about 180 model calls and network egress from wherever the tests run.
- decision A maintainer who likes the name classifier can still keep OS_FAMILY_MAP and skip the second call, because the table only needs the name the first call already produced.
- exposure Anyone porting an if/elif pile one branch at a time with fuzzy() inherits write order as the tie-break whenever two branches both clear the threshold, and nothing in the code shows which one lost.
fuzzy() is a bool with an HTTPS request under it. Jev returns a probability, 0.93 in the post's example, and the library compares it against a 0.5 threshold [3]. TypeSafe AI released Jev in September 2026 and calls it a "System One" model: it does not generate text, and what comes back is a probability, a choice among labels, or a position on a scale [2]. Because nothing is generated, a warm call takes about 0.25 s and produces about 20 output tokens, identical question and text pairs are cached, and the HTTPS connection is reused [4].
One branch costs that much. The Ansible rewrite spends two per host, so roughly half a second of round trip before the first task runs, if a label pick costs what the documented yes/no call costs [21]. fuzzy_batch puts several questions in one request, but it takes yes/no questions, and this code needs two label picks [7].
distribution.py went from 786 lines to 450 [13]. Take the 418 deleted lines off 786 and 368 of the original remain, so the replacement is about 82 lines [20]. What went was thirteen parse_distribution_file_* methods, one per release-file family, each an if/elif ladder over the file text; the SUSE parser alone is 67 lines [9][11].
The second model call is the one I would argue with. In the original, the parsers produced a name and OS_FAMILY_MAP turned that name into a family by lookup, about 70 hand-maintained entries [9]. The distribution key came back correct on all 90 fixtures [16]. If the name is right and it is a key in the table, the family follows with no inference at all. The rewrite asks the model a second question instead [12].
For 90 of 90 to transfer to your own ladder, the label set has to contain the answer already. Here the labels are the distribution names Ansible documents, with a one-line description each [12], and the fixtures are release-file contents captured from real machines covering 52 distributions [14]. Keeping that enumeration current is the job OS_FAMILY_MAP's 70 entries were doing [9]. Across all keys, 65 of the 90 fixtures agreed, about 72 percent [15][19].
The author wrote: "The short version: the judgement part of the pile was replaceable. The extraction part was not." [17] The per-key figures that would size the second half are not in the text available here, which gives distribution at 90 of 90 and stops at the os_family row [18].
What to watch
- Whether the os_family score, once the full per-key table is published, lands anywhere near the distribution key's 90 of 90.