Switch to dynamic uv-compiled requirements management#120
Switch to dynamic uv-compiled requirements management#120
Conversation
- Added `requirements.in`, `requirements-dev.in`, and `requirements-docs.in` for dependency management. - Configured `pyproject.toml` to use `hatch-requirements-txt` for dynamic dependencies. - Updated `.github/workflows/format_and_test.yml` to automatically re-compile requirements during formatting. - Maintained Python 3.10+ compatibility by pinning `docutils` and constraining `sphinx` in docs requirements. - Compiled lock-file versions into `.txt` files using `uv pip compile`.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
Reviewer's GuideTransitions dependency management from static entries in pyproject.toml to a dynamic, uv-compiled requirements workflow, wiring it into Hatch metadata and CI so pinned requirements are generated from .in files while preserving Python 3.10+ compatibility. Sequence diagram for CI run with uv compilation and hatch dynamic dependenciessequenceDiagram
actor Developer
participant Repo
participant GitHubActions
participant Uv
participant RequirementsIn
participant RequirementsTxt
participant UvLock
participant Hatchling
participant HatchReqHook
Developer->>Repo: Push commits
Repo-->>GitHubActions: Trigger Format_and_test workflow
GitHubActions->>Uv: uv pip compile requirements.in
Uv->>RequirementsIn: Read requirements.in
Uv->>RequirementsTxt: Write requirements.txt
Uv->>UvLock: Update lock entries
GitHubActions->>Uv: uv pip compile requirements-dev.in
Uv->>RequirementsIn: Read requirements-dev.in
Uv->>RequirementsTxt: Write requirements-dev.txt
Uv->>UvLock: Update lock entries
GitHubActions->>Uv: uv pip compile requirements-docs.in
Uv->>RequirementsIn: Read requirements-docs.in
Uv->>RequirementsTxt: Write requirements-docs.txt
Uv->>UvLock: Update lock entries
GitHubActions->>GitHubActions: Run tests and formatting
GitHubActions->>Hatchling: Build package
Hatchling->>HatchReqHook: Invoke metadata hook
HatchReqHook->>RequirementsTxt: Read pinned requirements
HatchReqHook-->>Hatchling: Provide dynamic dependencies
Hatchling-->>GitHubActions: Complete build with resolved deps
Flow diagram for dynamic requirements compilation and metadata generationflowchart TD
A[Edit requirements.in files
requirements.in
requirements-dev.in
requirements-docs.in] --> B[Commit changes to repository]
B --> C[GitHub Actions
Format_and_test workflow runs]
C --> D[Run uv pip compile
for each .in file
with --python-version 3.10]
D --> E[Generate and update
requirements.txt
requirements-dev.txt
requirements-docs.txt]
D --> F[Update uv.lock
with resolved versions]
E --> G[Run tests and formatting
using pinned requirements]
E --> H[Build package with hatchling]
H --> I[hatch-requirements-txt hook
reads .txt files]
I --> J[Populate dynamic
project dependencies and
optional-dependencies in pyproject.toml]
J --> K[Publish or distribute
built package]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refactors the project's dependency management system by transitioning from static Highlights
Changelog
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The workflow step that runs
git add requirements*.txtinside CI will create dirty commits that don’t exist locally; consider dropping thegit addand treating the compiled files as build artifacts rather than something modified during CI runs. - With
dependenciesandoptional-dependenciesnow fully dynamic, make sure the correspondingrequirements*.infiles actually capture the previous runtime/dev/docs dependencies (and any version bounds that matter), otherwise published wheels may end up missing required packages. - Since the project supports Python 3.10+, it’s safer to pass an explicit
--python-version 3.10(or similar minimum) touv pip compilein the workflow so the pinned requirements remain compatible with the lowest supported Python version rather than the CI runner’s current version.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The workflow step that runs `git add requirements*.txt` inside CI will create dirty commits that don’t exist locally; consider dropping the `git add` and treating the compiled files as build artifacts rather than something modified during CI runs.
- With `dependencies` and `optional-dependencies` now fully dynamic, make sure the corresponding `requirements*.in` files actually capture the previous runtime/dev/docs dependencies (and any version bounds that matter), otherwise published wheels may end up missing required packages.
- Since the project supports Python 3.10+, it’s safer to pass an explicit `--python-version 3.10` (or similar minimum) to `uv pip compile` in the workflow so the pinned requirements remain compatible with the lowest supported Python version rather than the CI runner’s current version.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request transitions the project's dependency management from static definitions in pyproject.toml to a dynamic, uv-based workflow using requirements.in files. This is a solid improvement for maintainability and reproducibility. The changes correctly update pyproject.toml to use hatch-requirements-txt, introduce requirements.in files for different dependency groups, and update the uv.lock file. I have one suggestion to add a comment explaining a specific version pin for docutils to aid future maintenance.
| pytest-asyncio | ||
| pytest-cov | ||
| twine | ||
| docutils==0.21.2 |
There was a problem hiding this comment.
For better maintainability, it would be helpful to add a comment explaining why docutils is pinned to this specific version. This will provide context for future developers who might need to update dependencies.
# Pinned to resolve a dependency conflict
docutils==0.21.2
1 participant
This change transitions the project from static dependencies in
pyproject.tomlto a more robustuv-based workflow usingrequirements.infiles.Key changes:
requirements.in,requirements-dev.in, andrequirements-docs.inwithout version constraints to allowuvto resolve the best versions.pyproject.tomlto use thehatch-requirements-txtbuild hook, markingdependenciesandoptional-dependenciesas dynamic.Format and testGitHub workflow to re-compile the.infiles into.txtfiles usinguv pip compilewhenever it runs, ensuring the pinned requirements stay up to date.sphinx9.x (which requires 3.12+) and the project's base requirement by constrainingsphinx < 8.0.0in the docs extra.uv.lockwith the new dynamic configuration.PR created automatically by Jules for task 2708042962590808586 started by @5hojib
Summary by Sourcery
Switch project dependency management to dynamic, uv-compiled requirements files and integrate this workflow into CI.
New Features:
Enhancements:
Build:
CI:
Chores: