Poetry pep621 ci

[natelastname]

User description

This PR streamlines the project’s developer and CI workflow by adopting a single, modern configuration model ("poetry first").

What this enables

• Immediate setup after cloning:

poetry install
poetry run pytest
poetry run ruff check .
poetry run mypy .

No additional config files or manual steps required.

• One source of truth for dependencies and tooling configuration via pyproject.toml
• Reproducible environments across machines and CI through poetry.lock
• CI behavior that mirrors local development, reducing “works on my machine” issues
• Cleaner contributor experience with fewer files to understand and maintain

Impact

• Faster onboarding for new contributors
• More predictable CI results
• Lower long-term maintenance overhead

No application logic or public APIs are changed.

---

PR Type

Enhancement, Configuration changes

---

Description

• Migrate to Poetry-first workflow with PEP 621 compliance

  • Switch build backend from setuptools to hatchling
  • Consolidate dev dependencies into Poetry groups

• Modernize CI/CD pipeline with Poetry integration

  • Update GitHub Actions to use Poetry 2.1.3
  • Add caching for Poetry virtual environments and dependencies

• Consolidate tooling configuration into pyproject.toml

  • Move Pyright config from pyrightconfig.json into [tool.pyright]
  • Move pytest config from pytest.ini into [tool.pytest.ini_options]
  • Streamline Ruff linting rules and add import sorting

• Remove redundant configuration files

  • Delete pyrightconfig.json and pytest.ini (now in pyproject.toml)

---

Diagram Walkthrough

flowchart LR
  A["setuptools + pip"] -->|"migrate"| B["Poetry + hatchling"]
  C["pyrightconfig.json"] -->|"consolidate"| D["pyproject.toml"]
  E["pytest.ini"] -->|"consolidate"| D
  F["pip install"] -->|"replace"| G["poetry install"]
  H["Manual CI steps"] -->|"streamline"| I["Poetry-driven CI"]
  B --> J["Single source of truth"]
  D --> J
  G --> J
  I --> J

Loading

File Walkthrough

Relevant files

Configuration changes

ci.yml Integrate Poetry into GitHub Actions CI workflow                  .github/workflows/ci.yml Replace pip-based dependency installation with Poetry Upgrade Poetry version to 2.1.3 in CI environment Add Poetry virtual environment caching for faster builds Update all test, lint, and type-check commands to use poetry run Fix YAML formatting (consistent spacing in branch lists) +45/-26  pyproject.toml Consolidate all tooling config into pyproject.toml              pyproject.toml Switch build backend from setuptools to hatchling Migrate dev dependencies from [project.optional-dependencies] to [tool.poetry.group.dev.dependencies] Create new [tool.poetry.group.docs.dependencies] group Move Pyright configuration from pyrightconfig.json into [tool.pyright] section Move pytest configuration from pytest.ini into [tool.pytest.ini_options] section Consolidate Ruff linting rules with simplified ignore list and import sorting Add hatchling build target configuration for wheel and sdist Reorganize and add comprehensive coverage configuration Update Black and Mypy configurations with improved formatting +211/-211 pyrightconfig.json Remove pyrightconfig.json (consolidated)                                  pyrightconfig.json File deleted entirely Configuration migrated to [tool.pyright] section in pyproject.toml +0/-46    pytest.ini Remove pytest.ini (consolidated)                                                  pytest.ini File deleted entirely Configuration migrated to [tool.pytest.ini_options] section in pyproject.toml +0/-18

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Unpinned GitHub Action Description: The workflow uses a third-party GitHub Action (snok/install-poetry@v1) pinned only to a mutable tag rather than an immutable commit SHA, which creates a supply-chain risk if the action tag is retargeted or the upstream is compromised. ci.yml [25-31] Referred Code - name: Install Poetry uses: snok/install-poetry@v1 with: version: "2.1.3" virtualenvs-create: true virtualenvs-in-project: true
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Use a valid Poetry version In the CI workflow, change the invalid Poetry version "2.1.3" to a valid one, such as latest, to prevent build failures. .github/workflows/ci.yml [25-30] - name: Install Poetry uses: snok/install-poetry@v1 with: - version: "2.1.3" + version: "latest" virtualenvs-create: true virtualenvs-in-project: true Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies an invalid Poetry version "2.1.3" in the CI workflow, which would cause all pipeline runs to fail.	High
	Correct the test coverage threshold In the [tool.pytest.ini_options] section, revert the --cov-fail-under value from 70 back to the original 3 to maintain strict test coverage standards. pyproject.toml [130-149] [tool.pytest.ini_options] testpaths = ["tests"] python_files = ["test_*.py", "*_test.py"] python_classes = ["Test*"] python_functions = ["test_*"] addopts = [ "-v", "--strict-markers", "--tb=short", "--cov=knowgraph", "--cov-report=html", "--cov-report=term-missing", - "--cov-fail-under=70", + "--cov-fail-under=3", ] markers = [ "slow: marks tests as slow (deselect with '-m \"not slow\"')", "integration: marks tests as integration tests", "unit: marks tests as unit tests", "benchmark: marks tests as performance benchmarks", ] Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a significant and likely unintentional weakening of the test coverage threshold from 3% to 70%, which could compromise code quality.	Medium
High-level	Standardize on a single type-checker The PR configures both Pyright and MyPy, but the CI only runs MyPy. To simplify the toolchain and reduce maintenance, the project should standardize on a single type-checker. Examples: pyproject.toml [89-278] [tool.pyright] include = ["knowgraph", "tests"] exclude = [ "**/__pycache__", "**/.pytest_cache", "**/.mypy_cache", "**/.ruff_cache", "**/node_modules", "**/.venv", "**/venv", ... (clipped 180 lines) .github/workflows/ci.yml [58-60] - name: Type check with MyPy run: | poetry run mypy . Solution Walkthrough: Before: # pyproject.toml [tool.poetry.group.dev.dependencies] mypy = "^1.8" pyright = "^1.1.380" ... [tool.pyright] # ... pyright configuration ... [tool.mypy] # ... mypy configuration ... # .github/workflows/ci.yml - name: Type check with MyPy run: | poetry run mypy . After: # pyproject.toml [tool.poetry.group.dev.dependencies] # mypy is removed pyright = "^1.1.380" ... [tool.pyright] # ... pyright configuration ... # [tool.mypy] section is removed # .github/workflows/ci.yml - name: Type check with Pyright run: | poetry run pyright . Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that configuring two type-checkers (Pyright and MyPy) contradicts the PR's goal of streamlining the development workflow, and standardizing on one would reduce complexity and maintenance.	Medium
More