Cookbook: one-click venv creation on server profiles (Venv button next to Check/Key)

[catagris]

Prerequisites

• I searched open issues and this has not already been proposed.
• I searched discussions and this is not already being debated there.
• This is a concrete, actionable proposal — not a vague "it would be nice if..." request.

Area

Cookbook / Local Models / GPU

Problem or Motivation

Pip installs and serve engines need a working Python environment on the target server, and on PEP 668 distros (Arch, newer Debian/Ubuntu) — or hosts whose python ships without pip entirely — the practical answer is always the same: create a venv and point the server profile's env/path fields at it. Today that's a manual, undocumented dance: ssh into the box, run python3 -m venv, come back to Odysseus, and hand-type the env type and path into the profile. New users hit this as a wall (see #5690 — a pip install on a pip-less python previously just hung as "running" forever) and even with the improved error message the remediation is still "go do shell work by hand".

Proposed Solution

A Venv button on each remote server entry in Settings → Servers, next to the existing Check and Key buttons (same pill styling, inline SVG icon, no new component patterns). Clicking it:

1. Calls a new admin-only POST /api/cookbook/setup-venv {host, ssh_port, path?} which runs python3 -m venv <path> on the target (default ~/odysseus-venv, or the profile's existing venv path if one is typed in) and verifies <path>/bin/python3 -m pip --version succeeds.
2. On success the UI sets the profile's env dropdown to venv, fills the path field, and persists — subsequent pip installs and serves target the venv automatically.
3. On failure the error is surfaced as a toast, including the Debian/Ubuntu case where ensurepip is stripped (the message names apt install python3-venv).

Implementation details: path validated against the same safe charset the shell routes already use for venv paths (interpolated unquoted so ~ expands remotely); the remote command runs via sh -lc so it works on non-POSIX login shells (fish/csh, see #5689); generous timeout because ensurepip bootstrapping can be slow on first run.

Alternatives Considered

• Document the manual steps only — keeps the wall in place; every remote server needs the same dance.
• Auto-create a venv implicitly on first pip install — too magical: it would silently pick a location on the user's machine and change profile config without consent. An explicit button keeps the user in control while removing the shell work.
• Install pip into the system python (--break-system-packages everywhere) — fights the distro instead of cooperating with it, and doesn't help pip-less pythons at all.

Prior Art / Related Issues

#5690 (pip installs on a pip-less python hang as "running" — the preflight fix there recommends a venv, this button makes that recommendation actionable in one click), #5689 (non-POSIX login shell fix that the remote command here builds on). The server profile already models env=venv + path; this only automates creating what those fields describe. Implementation ready as a PR (backend route + button + tests).

Are you willing to implement this?

Yes — I can open a PR