refactor(app)!: split requirements files

[nanotaboada]

Summary by CodeRabbit

• Chores

  • Streamlined project workflows and enhanced automation, improving overall system stability and maintainability.
  • Simplified dependency management with a focused set of core libraries for a more efficient application experience.
  • Introduced new linting and testing configurations for improved code quality and adherence to style guidelines.

• Tests

  • Refined internal test structure to improve clarity, ensuring robust quality assurance and more consistent performance.

These updates enhance the underlying processes for a more stable and efficient application, contributing indirectly to an improved end-user experience.

[coderabbitai]

Walkthrough

This pull request makes several adjustments to the project’s configuration and dependency management. The .flake8 file is updated with additional linting rules and reporting options. The GitHub Actions workflow is restructured into separate jobs for linting, testing, and coverage reporting using a dedicated environment variable. New dependency files for linting and testing have been introduced, while the main requirements.txt is streamlined to retain only essential packages. Additionally, test files are enhanced with structured comments to clarify test phases.

Changes

File(s)	Change Summary
.flake8	Added new settings: max-complexity = 10, select = E9,F63,F7,F82, exclude = .venv, count = True, show-source = True, statistics = True, and verbose = True (while retaining max-line-length = 127).
.github/workflows/python-app.yml	Restructured workflow: introduced env: PYTHON_VERSION: 3.9, split jobs into lint, test, and coverage, and simplified steps including conditional matrix logic for coverage report uploads.
requirements-lint.txt	Added dependency: flake8==7.1.2.
requirements-test.txt	New file created listing test dependencies: references requirements.txt, and includes pytest==8.3.5, pytest-cov==6.0.0, and pytest-sugar==1.0.0.
requirements.txt	Simplified dependencies: updated fastapi from 0.115.11 to fastapi[standard]==0.115.12 and removed numerous extraneous packages, retaining only fastapi[standard], fastapi-cache2, SQLAlchemy, and aiosqlite.
tests/test_main.py	Added # Arrange, # Act, and # Assert comments to test functions to clearly delineate the testing phases.

Sequence Diagram(s)

sequenceDiagram
    participant GitHub as "GitHub Actions"
    participant Lint as "Lint Job"
    participant Test as "Test Job"
    participant Coverage as "Coverage Job"
    participant CovService as "Coverage Service"

    GitHub->>Lint: Trigger Lint Job (with PYTHON_VERSION=3.9)
    Lint->>GitHub: Execute Flake8 checks using requirements-lint.txt
    GitHub->>Test: Trigger Test Job (with PYTHON_VERSION=3.9)
    Test->>GitHub: Run pytest, generate coverage artifact
    GitHub->>Coverage: Trigger Coverage Job (depends on Test output)
    Coverage->>CovService: Upload coverage report (selecting Codecov or Codacy)

Loading

Possibly related PRs

• chore(deps): bump flake8 from 7.1.0 to 7.1.1 #184: Addresses updates to the Flake8 configuration and linting dependency settings, which relate to the new .flake8 enhancement.

Suggested labels

dependencies, python

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.88%. Comparing base (fa3a773) to head (aea9c50).
Report is 4 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #318   +/-   ##
=======================================
  Coverage   88.88%   88.88%           
=======================================
  Files           2        2           
  Lines         108      108           
=======================================
  Hits           96       96           
  Misses         12       12           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.00%	✅ ∅

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (fa3a773)	272	260	95.59%
Head commit (aea9c50)	272 (+0)	260 (+0)	95.59% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#318)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

.flake8 (1)

8-13: Consider expanding error code selection

The current selection focuses on a subset of Flake8's error codes (syntax errors, operator issues, control flow issues, and undefined names). While these are important checks, you might consider including additional error codes like E2 (whitespace issues), E3 (blank line issues), and W (various warnings) for more comprehensive linting.

.github/workflows/python-app.yml (1)

12-13: Consider updating Python version

Using an environment variable for the Python version is a good practice for maintainability. However, Python 3.9 is becoming older (Python 3.12 is the latest stable version). Consider updating to a more recent version for better performance, security, and feature support.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2143d7c and aea9c50.

📒 Files selected for processing (6)

• .flake8 (1 hunks)
• .github/workflows/python-app.yml (1 hunks)
• requirements-lint.txt (1 hunks)
• requirements-test.txt (1 hunks)
• requirements.txt (1 hunks)
• tests/test_main.py (16 hunks)

🚧 Files skipped from review as they are similar to previous changes (3)

• requirements-lint.txt
• requirements-test.txt
• tests/test_main.py

🔇 Additional comments (8)

.flake8 (3)

5-6: Well-defined complexity threshold

Setting a maximum allowed code complexity of 10 is a good practice. This helps prevent overly complex functions that can be difficult to understand and maintain.

---

15-16: Standard exclusion pattern

Excluding the .venv directory is a good practice to prevent linting of dependency files.

---

18-28: Comprehensive reporting configuration

The added reporting options (count, show-source, statistics, and verbose) provide a more detailed linting output, which is helpful for debugging and understanding linting issues.

requirements.txt (2)

1-2: Good use of FastAPI extras

Using fastapi[standard] is a good practice as it bundles commonly used dependencies, making the requirements file cleaner. The version upgrade from 0.115.11 to 0.115.12 likely includes bug fixes.

---

1-6: Clean separation of dependencies

The simplification of this file to include only runtime dependencies aligns with the PR title "split requirements files". This separation of runtime dependencies from development dependencies (like testing and linting tools) follows best practices and makes dependency management more maintainable.

.github/workflows/python-app.yml (3)

15-36: Well-structured lint job

The dedicated linting job with a separate requirements file follows good practices for CI/CD pipelines. This makes it clear which dependencies are needed for linting and isolates the linting process from testing.

---

37-68: Effective test job configuration

The test job is well structured with appropriate dependency on the lint job. Using a separate requirements file for testing dependencies is a good practice. The generation and uploading of the coverage report as an artifact for use in subsequent jobs is an efficient approach.

---

69-96: Elegant matrix strategy for coverage reporting

Using a matrix strategy to upload coverage reports to both Codecov and Codacy in parallel is an excellent use of GitHub Actions' capabilities. This approach is more maintainable than having separate jobs or steps for each service.