Conversation
There was a problem hiding this comment.
Overall this change makes local backend startup much more reliable by preventing dependency drift.
Left one question inline about whether uv sync should include dev deps / preserve extras and whether we want to avoid rewriting uv.lock during ./rh dev backend.
|
|
||
| check_uv | ||
| echo -e "${BLUE}Installing backend packages (uv sync)...${NC}" | ||
| uv sync || { |
There was a problem hiding this comment.
Question: should ./rh dev backend run plain uv sync?
uv sync without flags will only sync the default deps and may also remove previously-installed optional extras (e.g. if someone uses --extra cpu/gpu) and won’t include the dev dependency group. If the intent is “dev env”, consider uv sync --dev and (if relevant) an env-var/flag to pass extras (or at least document the expected extras). Also consider using the lock-protecting flag (--frozen/--locked, depending on uv version) if you don’t want a backend start to rewrite uv.lock.
Purpose
Ensure the backend virtual environment matches
pyproject.tomlwhenever developers start the local backend, so dependency drift does not cause confusing import or version errors.What Changed
./rh dev backendnow runscheck_uv, prints a short status line, and runsuv syncinapps/backendbefore activating.venvand invokingstart.sh.uv syncfailures surface a clear error and exit before the server starts.Additional Context
Testing
./rh dev backendfrom the repo root and confirm the "Installing backend packages (uv sync)..." message appears and the backend starts as before.