Enable ruff security, logging and debugging rules (S, T20, LOG, G, DTZ, ERA, TD, FIX, EXE)
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 18/100
Línea de trabajo
The payload names no specific files, only the ruff rule groups (S, T20, LOG, G, DTZ, ERA, TD, FIX, EXE) and the S101 asserts, T20 prints, and DTZ datetimes they touch. Start with the ruff configuration in the repository and linked pull request #3915 to see which rules are already enabled and what has been fixed. Done means the new rules pass with each finding either fixed or suppressed with a stated reason, and error responses and published schemas are unchanged.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Phase 1 step 1.8, group 6 of the rules workstream: enable ruff's security, logging and debugging rules (S, T20, LOG, G, DTZ, ERA, TD, FIX, EXE).
- Security (
S): fix each finding, or keep it with an inline reason where it's a false positive (fake secrets in tests, repository commands run by tests, fixed container paths). - Asserts outside tests (
S101): replace type-narrowing asserts with explicit checks, without changing any error response. - Prints (
T20): remove debug prints from application code; command-line scripts keep their output, with a reason. - Logging (
LOG,G): module loggers and lazy formatting, with identical message text. - Datetimes (
DTZ): never switch a value between naive and aware; keep naive values that must stay naive, with a reason. - Leftovers (
ERA,TD,FIX,EXE): delete commented-out code, turn TODOs into plain notes or issue links, and match shebangs with the executable bit.
Error responses and published schemas must not change.
- Lenguaje dominante
- Python
- Estrellas
- 18
- Forks
- 33
- Merge medio
- 1 d 15 h
- PR fusionados (30 d)
- 18
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de PolicyEngine/policyengine-api
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
PolicyEngine/policyengine-api#3911 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
PolicyEngine/policyengine-api#3910 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
PolicyEngine/policyengine-api#3912 ·
Los mantenedores suelen responder en 1 día
-
validate_country prints "Validating country" on every requestPosiblemente ocupada @anth-volk la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 25/100
PolicyEngine/policyengine-api#3909 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 Medio día Aptitud para principiantes 48/100
PolicyEngine/policyengine-api#3908 ·
Los mantenedores suelen responder en 1 día
Todos los issues de PolicyEngine/policyengine-api
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
onyx-dot-app/onyx#16016 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
black --check exits 0 and prints All done when a multi file run is interruptedPosiblemente ocupada @jiteshgulati la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días
-
Non-positive worker counts wait for results without starting workersPosiblemente ocupada @IlyaKhalafi la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día