SCANPY-245 Fix strict dependencies pinning of pysonar

[guillaume-dequenne]

No description provided.

[hashicorp-vault-sonar-prod]

SCANPY-245

[sonar-review-alpha]

Summary

DEPENDENCY MANAGEMENT OVERHAUL. You've taken the rigid exact-pinning approach—every ingredient measured to the nanogram—and loosened it sensibly. Tomli, requests, and jproperties now float within semantic version ranges: >=2.0,<3, >=2.32,<3, >=2.1,<3 respectively. Test-only noise—responses and pyfakefs—yanked out of the main dependencies and relegated to dev where they belong. You also corrected a naming blunder: jfrog-server source renamed to repox. Result: a poetry.lock regeneration with 1247 lines of locked dependency states, reflecting cleaner ingredient sourcing. The application code itself is pristine—untouched. This is plumbing work done properly.

What reviewers should know

Start here: Ignore the poetry.lock mammoth—it's a mechanical consequence of loosening version constraints. Focus on pyproject.toml diffs. What changed: Three core dependencies relaxed from exact versions (e.g., 2.2.1) to safe ranges (e.g., >=2.0,<3), allowing patch and minor updates without forcing major version rewrites. Responses and pyfakefs properly exiled to dev dependencies—they're test infrastructure, not runtime requirements. Source reference renamed for clarity. Why it matters: Exact pinning is kitchen-prep laziness dressed as rigor. Sensible ranges (>=X,<MAJOR+1) preserve stability while allowing security patches and minor improvements through the supply chain without manual intervention. No gotchas: The source name change is cosmetic but necessary. Workflow files and CI config additions are supplementary infrastructure—they enable this dependency strategy. All ingredient measurements are sound.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

---

• 🐟 April Fools' persona mode!

[sonar-review-alpha]

Conclusion: The dependency changes are correct in intent — loosening pins for runtime deps and moving test libraries to dev. One question needs clarification before approving.

🗣️ Give feedback

[sonar-review-alpha]

The lock file was generated with Poetry 2.1.1, but the previous lock file was generated with 2.3.2. This is a downgrade. The mise toolchain in this repo pins specific tool versions — was this intentional? If CI or other developers run a different Poetry version (2.3.x), they may get a different lock file on next poetry lock, causing churn. Please confirm this matches the Poetry version pinned in .mise.toml / .tool-versions.

• Mark as noise

[joke1196]

LGTM! Do you need to add pygments 2.19, was version 2.20 not available?

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed for 'Python Scanner'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube