formatting.yml: job names 'format (black)' / 'format (isort)' are misleading — both run ruff
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 76/100
Direzione di ricerca
Inizia da .github/workflows/formatting.yml e confronta i nomi dei job con l’approccio di denominazione neutro in pythonlint.yml. Rinomina i check in modo che riflettano i comandi Ruff, rimuovi il commento sul nome legacy e documenta che i repository che usano i vecchi nomi dei check obbligatori devono aggiornare i propri ruleset.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
Since the ruff migration (#352 / #353), .github/workflows/formatting.yml no longer runs black or isort, but its jobs are still named after them:
name: "format (${{ matrix.tool }})"
...
matrix:
include:
- tool: black
command: ruff format --check .
- tool: isort
command: ruff check --select I .
The comment above explains the names are kept so the required status checks format (black) / format (isort) stay stable for branch protection.
Why it's misleading
- In the Checks UI and in branch rulesets, a failing "format (black)" suggests black is installed/configured — newcomers look for black config or try
black .locally. - Repositories created from the template inherit the legacy names even though they never used black/isort, so the "keep required check names stable" reason doesn't apply to them; they just copy the confusion (observed when building a new repo from this template).
pythonlint.ymlalready solved the same concern with a neutral, command-independent name ("Python Code Quality and Lint (...)").
Suggestion
- Rename the jobs to describe what runs, e.g.
Ruff format(ruff format --check .) andRuff import sorting(ruff check --select I .) — or one job "Ruff formatting" running both. - Note in the PR/README that repositories which use the old names as required checks must update their ruleset once.
- Drop the legacy comment afterwards.
- Lingua principale
- Python
- Stelle
- 8
- Fork
- 0
- Merge medio
- 2m
- PR unite (30g)
- 9
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Hochfrequenz/python_template_repository
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Hochfrequenz/python_template_repository#161 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Hochfrequenz/python_template_repository
Issue simili
-
bot-triaged module: LrScheduler module: optimizer triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
documentation glm5 llm-model
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
vllm-project/vllm-ascend#19062 ·
I maintainer di solito rispondono entro 1 giorno
-
Author Page: shuai-zhao-llmApertaauthor-page correction
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
acl-org/acl-anthology#10496 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Issue Type: Bug Report
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
celery/celery#10875 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
SasanLabs/VulnerableApp#836 ·
I maintainer di solito rispondono entro 1 giorno