Julia: `format(".")` + `git diff` + `exit(1)` is a formatting gate; biome via biome_jll in a julia -e one-liner

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#267 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
62/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
julia, python
Bereich
ci-cd, tooling

Rechercherichtung

Der falsch negative Befund kommt von der Regex _FAILS in project_validator/ecosystems/julia.py (etwa Zeile 169), die nur || exit(1) oder @assert format akzeptiert. Beginne mit dem JuMP.jl-Workflow unter corpus/ .github/workflows/format_check.yml, Zeilen 18-31, und prüfe, wie das Julia-Profil die Code-Formatierungsprüfung darin liest. Fertig ist, wenn dieser Workflow für code-formatting als PASS eingestuft wird, die bestehenden Julia-Korpuserwartungen weiterhin gelten und die Testsuite erfolgreich durchläuft. Das Biome-Element von Documenter.jl hat eine niedrige Konfidenz und kann in diesem Fix ausgelassen werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

JuMP.jl's format-check job runs format(".") and exits 1 when git diff is non-empty — exactly the "fails on a changed file" criterion the Julia profile documents — but the recogniser accepts only the literal || exit(1) or @assert format: FAIL "CI runs JuliaFormatter but only to rewrite files". Documenter.jl's make check-js runs biome check through the biome_jll wrapper inside a julia -e one-liner → code-formatting/static-analysis WARN.

Evidence from the corpus audit

jump-dev/JuMP.jl / code-formatting
  • kind: FALSE_NEGATIVE
  • actual: FAIL: CI runs JuliaFormatter but only to rewrite files; nothing fails when they are not formatted
  • expected: PASS: the format-check job runs format(".") and then exits 1 when git diff is non-empty, which is exactly the "fails on a file it changed" criterion the Julia profile documents; the recogniser only accepts the literal || exit(1) or @assert format.
  • evidence: .github/workflows/format_check.yml:18-31: shell: julia --color=yes {0} / run: | / ... / format("."; verbose = true) / out = String(read(Cmd(\git diff`)))/ if isempty(out)/ exit(0)/ end/ @error "Some files have not been formatted !!!"/ write(stdout, out)/ exit(1); project_validator/ecosystems/julia.py:169: _FAILS = re.compile(r"||\sexit\s(\s1\s)|@assert\s+format")`
  • repro: the 12-line julia step above in a workflow with shell: julia --color=yes {0}
  • confidence: high
JuliaDocs/Documenter.jl / code-formatting, static-analysis (Biome via biome_jll)
  • kind: UNSUPPORTED
  • actual: code-formatting WARN .prettierrc, biome.jsonc is defined but CI does not run prettier, deno fmt, oxfmt, dprint or biome; static-analysis WARN biome is configured (biome.jsonc) but does not run
  • expected: CI's "Biome (JS code formatting)" job runs make check-js, whose recipe runs biome check through the Julia biome_jll wrapper and exits with biome's status. The Makefile target is followed (no unread reason) but the biome invocation inside a julia one-liner is not recognised.
  • evidence: .github/workflows/CI.yml:315-324: biome: / name: Biome (JS code formatting) ... - run: make install-biome / - run: make check-js; Makefile:37-38: check-js: / julia --project=$(BIOME) -e 'using biome_jll; exit(run(ignorestatus(\$$(biome_jll.biome()) check`)).exitcode)'`
  • repro: Makefile target with the recipe above + run: make check-js
  • confidence: low (exotic; listed for completeness)

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.