Fix/isort python39 compatibility

[BrandtKruger]

fix: make isort conditional to maintain Python 3.9 compatibility

• Add conditional isort installation in [project.optional-dependencies]
  • Python 3.10+: isort >=7.0.0
  • Python 3.9: isort >=5.12.0, <7.0
• Remove hardcoded isort from [tool.poetry.dev-dependencies]
• Update requirements.txt with documentation comment
• Maintains backwards compatibility with Python 3.9 while allowing
  Python 3.10+ users to use isort v7

Fixes Python 3.9 CI/CD compatibility issue with isort v7 upgrade.
This PR builds on top of PR #126 (isort v7 upgrade).

Checklist

• I have read the “Pull requests” section in the contributing guidelines.
• I agree to the terms within the code of conduct.

🛟 If you need help, consider asking for advice over in the Kinde community.

[coderabbitai]

Walkthrough

Comments added to requirements.txt documenting conditional isort versioning based on Python version, editable dev install instructions, and Python 3.9 CI/CD compatibility notes. Existing isort dependency specification unchanged.

Changes

Cohort / File(s)	Summary
Documentation comments requirements.txt	Added explanatory comments regarding isort version conditionals, editable mode installation guidance, and Python 3.9 compatibility for CI/CD without modifying actual dependency versions

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: fixing isort Python 3.9 compatibility, which matches the primary objective of the changeset.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, providing context about conditional isort versioning, affected Python versions, and the compatibility issue being resolved.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7deb113 and 8789403.

⛔ Files ignored due to path filters (1)

• pyproject.toml is excluded by !**/*.toml

📒 Files selected for processing (1)

• requirements.txt (1 hunks)

🔇 Additional comments (1)

requirements.txt (1)

30-34: Based on my verification, I can now provide the rewritten review comment. Here's what I found:

The review comment's core concerns are valid, but the proposed changes appear incomplete or misaligned with the current project structure.

The current codebase shows:

• pyproject.toml uses Poetry ([tool.poetry.dev-dependencies]) with isort = "^5.12.0" (which restricts to <6.0)
• pyproject.toml has [project.optional-dependencies] for only fastapi and flask, NOT for dev tools
• requirements.txt currently has isort>=5.12.0 without comments or upper bounds

The review comment assumes a setup using [project.optional-dependencies] with conditional isort versioning by Python version, but this doesn't currently exist in the project structure. This suggests the PR may be proposing a significant refactor of the dependency management system.

---

The proposed requirements.txt changes need clarification on how conditional installation will work.

The review comment documents intent for conditional isort versioning (Python 3.10+: ≥7.0.0, Python 3.9: ≥5.12.0 <7.0), but the proposed line 34 specifies isort>=5.12.0 without an upper bound constraint. This version specification could install isort 7+ on Python 3.10+ systems if requirements.txt is used directly (e.g., pip install -r requirements.txt), bypassing the intended conditional logic.

Verify the following before proceeding:

1. Is this PR migrating from Poetry [tool.poetry.dev-dependencies] to setuptools [project.optional-dependencies]? The current pyproject.toml doesn't have dev tools in optional-dependencies.
2. If conditional installation via [project.optional-dependencies] will be implemented, confirm that pyproject.toml has been updated to define separate isort versions for Python 3.9 vs 3.10+.
3. If requirements.txt is used directly for development, line 34 should include the upper bound (isort>=5.12.0,<7.0) to prevent isort 7+ installation on Python 3.9.
4. Confirm whether pip install -e ".[dev]" is the recommended workflow or if pip install -r requirements.txt is also expected to be used.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[dtoxvanilla1991]

Line 34 currently pins isort>=5.12.0 unconditionally in requirements.txt, so any workflow that still relies on pip install -r requirements.txt (many CI jobs do) will keep pulling the 5.x series even on Python 3.10+. That contradicts the PR’s stated goal of allowing 3.10+ to use isort 7.

If you really expect everyone—including automation—to switch to pip install -e ".[dev]", then yes, that isort line should be removed so there isn’t a conflicting requirement. But before dropping it, confirm that no CI/CD paths still consume requirements.txt; otherwise you’ll lose isort entirely there. A safer alternative is to keep entries in requirements.txt but mirror the conditional markers already used in pyproject.toml,

[dtoxvanilla1991]

We currently still pin isort>=5.12.0 unconditionally in requirements.txt, so any workflow that still relies on pip install -r requirements.txt (many CI jobs do) will keep pulling the 5.x series even on Python 3.10+. That contradicts the PR’s stated goal of allowing 3.10+ to use isort 7.

If you really expect everyone - including automation - to switch to pip install -e ".[dev]", that isort line should be removed so there isn’t a conflicting requirement. But before dropping it, confirm that no CI/CD paths still consume requirements.txt; otherwise we’ll lose isort entirely there. A safer alternative is to keep entries in requirements.txt but mirror the conditional markers already used in pyproject.toml. To align intent and behavior you either:

• Add the same conditional markers to requirements.txt, or
• Remove isort from requirements.txt entirely (and ensure all pipelines use the extras path).