Remove pip-tools, use uv for all operations

docs/guide/config.md

@@ -82,7 +82,8 @@ force-rye-managed = false
 global-python = false
 
 # When set to `true`, Rye will use `uv` for package resolution and installation.
-# Set to `false` to fall back to the `pip-tools` resolver.
+# `uv` is the only engine in use at this point and setting this to false will produce a warning
+# This flag will be deprecated in a future version.
 # Learn more about uv here: https://github.com/astral-sh/uv
 use-uv = true
 

docs/guide/docker.md

@@ -14,11 +14,29 @@ This guide requires some familiarity with Docker and Dockerfiles.
      - Your `pyproject.toml` should contain `virtual = true` under the `[tool.rye]` section. If it's not there, add it and run `rye sync`.
      - If you're just setting up a project, run `rye init --virtual` instead of `rye init`.
 
-1. Create a `Dockerfile` in your project root with the following content:
+2. Create a `Dockerfile` in your project root with the following content, using [`uv`](https://github.com/astral-sh/uv):
 
     ```Dockerfile
     FROM python:slim
 
+    # see below for other uv install options
+    RUN pip install uv
+
+    WORKDIR /app
+    COPY requirements.lock ./
+    RUN PYTHONDONTWRITEBYTECODE=1 uv pip install --no-cache-dir -r requirements.lock
+
+    COPY src .
+    CMD python main.py
+    ```
+
+    Other [`uv`](https://github.com/astral-sh/uv) install options [here](https://github.com/astral-sh/uv?tab=readme-ov-file#getting-started)
+
+    Or using pip:
+
+    ```Dockerfile
+    FROM python:slim
+
     WORKDIR /app
     COPY requirements.lock ./
     RUN PYTHONDONTWRITEBYTECODE=1 pip install --no-cache-dir -r requirements.lock
@@ -27,7 +45,7 @@ This guide requires some familiarity with Docker and Dockerfiles.
     CMD python main.py
     ```
 
-2. You can now build your image like this:
+3. You can now build your image like this:
 
     ```bash
     docker build .
@@ -56,11 +74,12 @@ The `Dockerfile`s in this guide are examples. Some adjustments you might want to
 If your code is an installable package, it's recommended that you first build it, then install it inside your Docker image.
 This way you can be sure that the image is exactly the same as what a user installation would be.
 
-An example `Dockerfile` might look like this:
+An example `Dockerfile` might look like this with [`uv`](https://github.com/astral-sh/uv):
 
 ```Dockerfile
 FROM python:slim
-RUN --mount=source=dist,target=/dist PYTHONDONTWRITEBYTECODE=1 pip install --no-cache-dir /dist/*.whl
+RUN pip install uv
+RUN --mount=source=dist,target=/dist PYTHONDONTWRITEBYTECODE=1 uv pip install --no-cache-dir /dist/*.whl
 CMD python -m my_package
 ```
 
@@ -78,8 +97,8 @@ The [Dockerfile adjustments from the previous section](#dockerfile-adjustments)
 
 ## Explanations
 
-Rye's lock file standard is the `requirements.txt` format from `pip`, so you don't actually need `rye` in your container to be able to install dependencies.
+Rye's lock file standard is the `requirements.txt` format from `pip` and used by [`uv`](https://github.com/astral-sh/uv), so you don't actually need `rye` in your container to be able to install dependencies.
 This makes the Dockerfile much simpler and avoids the necessity for multi-stage builds if small images are desired.
 
-The `PYTHONDONTWRITEBYTECODE=1` env var and `--no-cache-dir` parameters when invoking Pip both make the image smaller by not writing any temporary files.
-Both Bytecode and Pip caches are speeding things up when running Pip multiple times, but since we are working in a container, we can be pretty sure that we'll never invoke pip again.
+The `PYTHONDONTWRITEBYTECODE=1` env var and `--no-cache-dir` parameters when invoking [`uv`](https://github.com/astral-sh/uv) and `pip` both make the image smaller by not writing any temporary files.
+Both Bytecode and [`uv`](https://github.com/astral-sh/uv)/`pip` caches are speeding things up when running installs multiple times, but since we are working in a container, we can be pretty sure that we'll never invoke [`uv`](https://github.com/astral-sh/uv) or `pip` again.

docs/guide/rust.md

@@ -41,14 +41,6 @@ it as a global tool:
 rye install maturin
 ```
 
-Note that `maturin develop` requires `pip` to be installed into the virtualenv.  Before
-you can use it you need to add it:
-
-```
-rye add --dev pip
-rye sync
-```
-
 Rye recommends mixed python/rust modules.  In that case you can save some valuable
 iteration time by running `maturin develop --skip-install`:
 

docs/guide/sync.md

@@ -1,10 +1,6 @@
 # Syncing and Locking
 
-Rye supports two systems to manage dependencies:
-[uv](https://github.com/astral-sh/uv) and
-[pip-tools](https://github.com/jazzband/pip-tools).  It currently defaults to
-`uv` as it offers significantly better performance, but will offer you the
-option to use `pip-tools` instead.
+Rye supports only supports [`uv`](https://github.com/astral-sh/uv) to manage dependencies.
 
 In order to download dependencies rye creates two "lockfiles" (called
 `requirements.lock` and `requirements-dev.lock`).  These are not real lockfiles
@@ -67,7 +63,7 @@ rye lock Flask --pre
 
 By default (unless the `tool.rye.lock-with-sources` config key is set to `true` in the
 `pyproject.toml`) lock files are not generated with source references.  This means that
-if custom sources are used the lock file cannot be installed via `pip` unless also
+if custom sources are used the lock file cannot be installed via `uv` or `pip` unless
 `--find-links` and other parameters are manually passed.  This can be particularly useful
 when the lock file is used for docker image builds.
 
@@ -103,7 +99,7 @@ rye sync --no-dev
 ## Limitations
 
 Lockfiles depend on the platform they were generated on. This is a known limitation
-in pip-tools.
+in `uv` and `pip-tools`.
 
 For example, if your project relies on platform-specific packages and you generate
 lockfiles on Windows, these lockfiles will include Windows-specific projects.

docs/philosophy.md

@@ -14,10 +14,9 @@ on my mind when I built it:
 - **No Core Non Standard Stuff:** Rye (with the exception of it's own `tool` section
   in the `pyproject.toml`) uses standardized keys. That means it uses regular
   requirements as you would expect. It also does not use a custom lock file
-  format and uses [`uv`](https://github.com/astral-sh/uv) and
-  [`pip-tools`](https://github.com/jazzband/pip-tools) behind the scenes.
+  format and uses [`uv`](https://github.com/astral-sh/uv).
 
-- **No Pip:** Rye uses pip, but it does not expose it. It manages dependencies in
+- **No Pip:** Rye uses [`uv`](https://github.com/astral-sh/uv) only at this point. It manages dependencies in
   `pyproject.toml` only.
 
 - **No System Python:** I can't deal with any more linux distribution weird Python
@@ -53,11 +52,6 @@ lack of standardization. Here is what this project ran into over the years:
   which allows both remote and local references to co-exist and it rewrites them
   on publish.
 
-- **No Exposed Pip:** pip is intentionally not exposed. If you were to install something
-  into the virtualenv, it disappears next time you sync. If you symlink `rye` to
-  `~/.rye/shims/pip` you can get access to pip without installing it into the
-  virtualenv. There be dragons.
-
 - **No Workspace Spec:** for monorepos and things of that nature, the Python ecosystem
   would need a definition of workspaces. Today that does not exist which forces every
   tool to come up with it's own solutions to this problem.

rye/src/bootstrap.rs

@@ -12,7 +12,6 @@ use once_cell::sync::Lazy;
 use tempfile::tempdir_in;
 
 use crate::config::Config;
-use crate::piptools::LATEST_PIP;
 use crate::platform::{
     get_app_dir, get_canonical_py_path, get_python_bin_within, get_toolchain_python_bin,
     list_known_toolchains,
@@ -154,8 +153,8 @@ pub fn ensure_self_venv_with_toolchain(
         let uv_venv = uv.venv(&venv_dir, &py_bin, &version, None)?;
         // write our marker
         uv_venv.write_marker()?;
-        // update pip and our requirements
-        uv_venv.update(LATEST_PIP, SELF_REQUIREMENTS)?;
+        // update our requirements
+        uv_venv.update_requirements(SELF_REQUIREMENTS)?;
 
         // Update the shims
         let shims = app_dir.join("shims");