Simpler.Grants.gov Public Wiki
Grants.govSimpler.Grants.govGitHubDiscourse
  • 👋Welcome
  • GET INVOLVED
    • Why open source?
    • How to contribute code
    • How to file issues
      • Report a bug
      • Request a feature
      • Report a security vulnerability
    • Community guidelines
      • Code of Conduct
      • Reporting and removing content
      • Incident response protocol
    • Community events
      • Fall 2024 Coding Challenge
        • Event Submissions & Winners
      • Spring 2025 Collaborative Coding Challenge
        • Event Submissions & Winners
    • Communication channels
  • Product
    • Roadmap
    • Deliverables
      • 🏁Static site soft launch
      • 🏁Static site public launch
      • 🏁GET Opportunities
      • 🏁Open source onboarding
      • 🏁Co-Design Group planning
    • Decisions
      • ADR Template
      • ADRs
        • Dedicated Forum for Simpler.Grants.gov Community
        • Recording Architecture Decisions
        • Task Runner for the CI / CD Pipeline
        • API Language
        • Use Figma for design prototyping
        • ADR: Chat
        • DB Choices
        • API Framework and Libraries
        • Back-end Code Quality Tools
        • Front-end Language
        • Communications Tooling: Wiki Platform
        • Use Mural for design diagrams and whiteboarding
        • Ticket Tracking
        • Front-end Framework
        • Front-end Code Quality Tools
        • Front-end Testing & Coverage
        • Backend API Type
        • Front-end Testing & Coverage
        • Deployment Strategy
        • Use U.S. Web Design System for components and utility classes
        • FE server rendering
        • Use NPM over Yarn Architectural Decision Records
        • U.S. Web Design System in React
        • Communications Tooling: Video Conferencing
        • Back-end Production Server
        • Communications Tooling: Analytics Platform
        • Commit and Branch Conventions and Release Workflow
        • Cloud Platform to Host the Project
        • Infrastructure as Code Tool
        • Data Replication Strategy & Tool
        • HHS Communications Site
        • Communications Tooling: Email Marketing
        • Communications Tooling: Listserv
        • Use Ethnio for design research
        • Uptime Monitoring
        • Database Migrations
        • 30k ft deliverable reporting strategy
        • Public measurement dashboard architecture
        • Method and technology for "Contact Us" CTA
        • E2E / Integration Testing Framework
        • Logging and Monitoring Platform
        • Dashboard Data Storage
        • Dashboard Data Tool
        • Search Engine
        • Document Storage
        • Document Sharing
        • Internal Wiki ADR
        • Shared Team Calendar Platform
        • Cross-Program Team Health Survey Tool
        • Adding Slack Users to SimplerGrants Slack Workspace
        • Repo organization
        • Internal knowledge management
        • Migrate Existing API Consumers
      • Infra
        • Use markdown architectural decision records
        • CI/CD interface
        • Use custom implementation of GitHub OIDC
        • Manage ECR in prod account module
        • Separate terraform backend configs into separate config files
        • Database module design
        • Provision database users with serverless function
        • Database migration architecture
        • Consolidate infra config from tfvars files into config module
        • Environment use cases
        • Production networking long term state
    • Analytics
      • Open source community metrics
      • API metrics
  • DESIGN & RESEARCH
    • Brand guidelines
      • Logo
      • Colors
      • Grid and composition
      • Typography
      • Iconography
      • Photos and illustrations
    • Content guidelines
      • Voice and tone
      • Editoral style
      • Terminology usage
    • User research
      • Grants.gov archetypes
  • REFERENCES
    • Glossary
  • How to edit the wiki
Powered by GitBook
On this page
  • Context and Problem Statement
  • Decision Drivers
  • Options Considered
  • Dependency Management
  • Code Linting
  • Auto-formatting
  • Type Checking
  • Security
  • License Checking
  • Interface
  • Decision Outcome
  • Other Options

Was this helpful?

Edit on GitHub
  1. Product
  2. Decisions
  3. ADRs

Back-end Code Quality Tools

  • Status: Active

  • Last Modified: 2023-07-07

  • Related Issue: #101

  • Deciders: Aaron, Daphne, Sammy, Gina, Lucas, Billy

  • Tags: ADR

Context and Problem Statement

Back-end code quality tools should facilitate and efficiently enforce linting, auto-formatting, type-checking and security concerns. They should be easily configurable to suit our specific use-cases, uniformly applying conventions while alleviating the need for individual intervention.

Decision Drivers

  • Ease of use and configurability: Code quality tools should be configurable to meet the specific needs of our project and enforce standards uniformly. Running the tool should be simple, and feedback should be easily implementable and understandable.

  • Speed: Code quality tools should be able to run in an timely manner, ideally in a pre-commit hook.

  • Documentation and resources: Code quality tools should have robust and helpful documentation, specifically around usage and configuration.

  • Lean: Selection of code quality tools should cover all use-cases with little overlap for ease of use and to minimize mental surface area required to understand the system. As in, each tool should have a specific, meaningful purpose.

  • Enforces security: Tooling should assist us in identifying security concerns and vulnerabilities.

  • Well-maintained: We have a preference towards libraries that are widely adopted and have active maintainers.

Options Considered

  1. Use a curated collection of Python libraries from Flask template repository (described below)

  2. Use a different or modified set of Python libraries

Dependency Management

Poetry: Python packaging and dependency management.

Code Linting

Ruff: An extremely fast Python linter, written in Rust. Preferred for its speed and growing community adoption.

Auto-formatting

Black: Format Python code. Compatible with Ruff out of the box, however, Ruff may replace the need for Black at some point. See this issue.

Type Checking

Mypy: Validate and enforce static type checking in Python.

Security

Safety: Safety first! Safety scans dependencies for vulnerabilities and security concerns.

License

pip-licenses: CLI tool for checking the software license of installed Python packages with pip.

Interface

Make: Run scripts, linters and formatters.

Decision Outcome

Option #2 is preferred. We would like to use Ruff for linting and add some additional libraries for security and license checks.

We will be using the Flask template repository for initial project set up, which already relies on Flake8 and several additional extensions (bugbear, alfred, bandit) that would be redundant with Ruff. Some extra work will need to be done to migrate away from Flake8 and to Ruff without any regression. Recommend using flake8-to-ruff to convert existing configuration.

There are some additional packages that we desire to use that are not included in the Flask template: safety & pip-licenses.

As we iterate on the tools that work for us, we would like to investigate a possible switch to Pyright in the future as well.

Other Options

Adopting Tox as a testing / linting manager with some of the libraries.

Dependency Management: Pipenv

Code Linting: Flake8: Much slower than Ruff. Requires additional extentions like bugbear that are built into Ruff. Pylint

Auto-formatting: autopep8

Type Checking: Pyright: Comparison of MyPy and Pyright. Language service through Pylance. Pyre

Security: Bandit: Security checking tool used to identify common concerns in Python code. Redundant because Ruff implements flake8-bandit. dependency-check

License Checking: licensecheck

Interface: Bash, Poetry

PreviousAPI Framework and LibrariesNextFront-end Language

Last updated 2 months ago

Was this helpful?