[Release] Synchronize for release

.tests/serve_test.sh

@@ -20,29 +20,39 @@ get_reboot_version_from() {
   echo $version
 }
 
+get_reboot_version_from_lock() {
+  # In a `uv.lock` the version is on the line following the package
+  # name, e.g.:
+  #   name = "reboot"
+  #   version = "1.1.0"
+  version=$(grep -A 1 '^name = "reboot"$' $1 | egrep -o '[.0-9]+' | head -n 1)
+  if [ -z "$version" ]; then
+    echo "No reboot version found in $1."
+    exit 1
+  fi
+  echo "reboot==$version"
+}
+
 # During Reboot's release process, consumed versions (but not lockfiles) have
 # been updated everywhere. During that period, our image claims to consume a
 # a version which does not yet exist. Rather than adding a bunch of conditionals to
 # our Dockerfile, which would make it harder to grok, we skip this test while the
 # lockfile is out of sync. See #3495.
-if [[ $(get_reboot_version_from "pyproject.toml") != $(get_reboot_version_from "requirements.lock") ]]; then
+if [[ $(get_reboot_version_from "pyproject.toml") != $(get_reboot_version_from_lock "uv.lock") ]]; then
   echo "Lockfile does not match pyproject.toml: assuming we're mid-publish."
   exit 0
 fi
 
-# Use the published Reboot pip package by default, but allow the test system
-# to override it with a different value. This is important even when using the
-# `reboot-base` image with the `reboot` package already installed, since the
-# `requirements.lock` file in this example might be out of date with the version
-# of `reboot` used in that base image, and in particular may list the wrong
-# dependencies.
-if [ -n "$REBOOT_WHL_FILE" ]; then
-  # Install the `reboot` package from the specified path explicitly, over-
-  # writing the version from `pyproject.toml`.
-  rye remove --no-sync reboot
-  rye remove --no-sync --dev reboot
-  rye add --dev reboot --absolute --path="${SANDBOX_ROOT}$REBOOT_WHL_FILE"
-fi
+# When run under Bazel, this test DOES exercise the unpublished dev
+# version of Reboot. This version is installed in the dev version of
+# Reboot base image, not through this project's lockfile: the
+# `setup_script` (see `reboot/containers/reboot-base/build.sh`) builds
+# the `ghcr.io/reboot-dev/reboot-base:<version>` image locally from
+# `$REBOOT_WHL_FILE`, and the example's `FROM` line picks that image
+# up. The `pip install` of the `uv export`ed lockfile inside the
+# Docker build then leaves that dev install in place, because the dev
+# wheel reports the same version that `uv.lock` pins (pip treats the
+# requirement as already satisfied).
 
 stop_container() {
   if [ -n "$container_id" ]; then

.tests/test.sh

@@ -23,13 +23,20 @@ check_lines_in_file() {
 if [ -n "$REBOOT_WHL_FILE" ]; then
   # Install the `reboot` package from the specified path explicitly, over-
   # writing the version from `pyproject.toml`.
-  rye remove --no-sync reboot
-  rye remove --no-sync --dev reboot
-  rye add --dev reboot --absolute --path="${SANDBOX_ROOT}$REBOOT_WHL_FILE"
+  uv add --no-sync "${SANDBOX_ROOT}$REBOOT_WHL_FILE"
 fi
 
-# Create and activate a virtual environment.
-rye sync --no-lock
+# Force a fresh virtualenv. A pre-existing `.venv/` (e.g., carried
+# over from a pre-baked image, or copied between containers/host
+# paths during the dev-container test) has its original creation
+# path baked into its `activate` script and console-script
+# shebangs, which breaks them when the venv is used from a
+# different location. `uv sync` only regenerates entry-point
+# scripts for packages it reinstalls, so it can't repair a
+# relocated venv. Nuking and re-syncing guarantees the venv lives
+# at the current path, which makes it safe to `activate`.
+rm -rf .venv
+uv sync
 source .venv/bin/activate
 
 # When running in a Bazel test, our `.rbtrc` file ends up in a very deep

Dockerfile

@@ -1,11 +1,16 @@
-FROM ghcr.io/reboot-dev/reboot-base:1.1.0
+FROM ghcr.io/reboot-dev/reboot-base:1.2.0
 
 WORKDIR /app
 
-# First ONLY copy and install the requirements, so that changes outside
-# `requirements.txt` don't force a re-install of all dependencies.
-COPY requirements.lock requirements.txt
-RUN pip install -r requirements.txt
+# First ONLY copy and install the dependencies, so that changes to the
+# application code don't force a re-install of all dependencies. `pip`
+# can't read `uv.lock` directly, so use `uv` itself to export it to
+# `requirements.txt` format.
+COPY --from=ghcr.io/astral-sh/uv:0.11.13 /uv /usr/local/bin/uv
+COPY pyproject.toml uv.lock ./
+RUN uv export --frozen --no-dev --no-emit-project \
+    --format requirements-txt -o requirements.txt \
+    && pip install -r requirements.txt
 
 # Next, copy the API definition and generate Reboot code. This step is also
 # separate so it is only repeated if the `api/` code changes.

README.md

@@ -43,7 +43,7 @@ Running directly on a host requires:
    - Linux: `x86_64` or `arm64`, with `glibc>=2.35` (Ubuntu Jammy and other equivalent-generation distributions)
    - Mac: `arm64` (Apple M1 and newer) with `MacOS>=14.0` and `Xcode>=15.2`
    - ... or [talk to us](https://discord.gg/cRbdcS94Nr) if your desired platform isn't currently supported!
-- [Rye](https://rye-up.com/) - A tool to manage `python`, `pip`, and `venv`.
+- [uv](https://docs.astral.sh/uv/) - A tool to manage `python`, `pip`, and `venv`.
    - If you are already familiar with Python [virtual environments](https://docs.python.org/3/library/venv.html), feel free to use your tool of choice with [`pyproject.toml`](./pyproject.toml). Python >= 3.10 and < 3.13 is required.
 - Node.js
     - Including `npm`.
@@ -64,9 +64,9 @@ running it. The most notable of those dependencies is the `reboot` PyPI
 distribution, which contains both the Reboot CLI (`rbt`) and the `reboot`
 Python package.
 
-Using `rye`, we can create and activate a virtualenv containing this project's dependencies (as well as fetch an appropriate Python version) using:
+Using `uv`, we can create and activate a virtualenv containing this project's dependencies (as well as fetch an appropriate Python version) using:
 ```sh
-rye sync --no-lock
+uv sync
 source .venv/bin/activate
 ```
 

pyproject.toml

@@ -1,18 +1,18 @@
 [project]
+name = "chat-room"
+version = "0.1.0"
 requires-python = ">= 3.10"
 dependencies = [
-    "reboot==1.1.0",
+    "reboot==1.2.0",
 ]
 
-[tool.rye]
-dev-dependencies = [
+[dependency-groups]
+dev = [
     "mypy==1.18.1",
     "pytest>=7.4.2",
     "types-protobuf>=4.24.0.20240129",
-    "reboot==1.1.0",
 ]
 
-# This project only uses `rye` to provide `python` and its dependencies, so
-# these settings remove the need to name or version the project.
-virtual = true
-managed = true
+# There is no `[build-system]` table: that tells `uv` this is a virtual
+# (non-package) project — it installs the dependencies into `.venv` but
+# never tries to build/install the project itself.

reboot-non-react-web/package.json

@@ -10,7 +10,7 @@
   },
   "dependencies": {
     "@bufbuild/protobuf": "1.10.1",
-    "@reboot-dev/reboot-web": "1.1.0",
+    "@reboot-dev/reboot-web": "1.2.0",
     "@testing-library/jest-dom": "^5.17.0",
     "@testing-library/user-event": "^13.5.0",
     "@types/jest": "^27.5.2",