* Let uv see the project before syncing it
uv refuses to run when a project pins a required-version it does not
match, in either direction: RomM pins ==0.12.13, which fails against
both the 0.10.3 a container was built with and the 0.12.17 latest
installs.
UV_PROJECT_DIR points setup_uv at the project so it reads that pin. It
is a prefix like PYTHON_VERSION and UV_VERSION, and the call sits
directly under fetch_and_deploy: the project is on disk by then, and
the deploy has closed its message block, which setup_uv needs since it
opens one of its own. That is also the only call needed - nothing
between the old early call and the deploy uses uv or Python, so the two
collapse into one.
Two things found along the way:
UV_PYTHON was set as a command prefix on setup_uv in 14 places. setup_uv
reads PYTHON_VERSION, never UV_PYTHON, and a prefix assignment does not
outlive the call, so those pins did nothing. They now use
PYTHON_VERSION, which installs the interpreter they were asking for.
Five update scripts had no setup_uv at all while their install
counterpart pinned a Python version. They now carry the same pin.
immich is left out: it runs uv through sudo -u inside a retry loop.
* yubal: drop the uv 0.7.19 pin
The pin came in with the script and was never explained. uv 0.7.19 is
from 2025-07-02; yubal's uv.lock has carried revision 3 since at least
2025-12-27, and older uv refuses a newer lockfile revision. The script
runs uv sync --frozen, so there is no fallback.
yubal declares no required-version of its own, so latest is what it
gets - and if it ever pins one, that pin is now honoured.
* suggestarr: keep the data where the app actually reads it
The env file sets CONFIG_DIR=/opt/suggestarr_data and the service passes
it through, but SuggestArr never reads that variable. Its database
manager builds the path from the application directory:
DB_PATH = os.path.join(BASE_DIR, 'config', 'config_files', 'requests.db')
so config.yaml, requests.db and secret.key live under /opt/suggestarr,
which the update wipes with CLEAN_INSTALL. Every update came back as a
fresh install.
Make config/config_files a symlink to /opt/suggestarr_data and lay it
down again after each deploy, since the deploy replaces it with a real
directory. Existing installs have their files copied across first, with
cp -an so anything already in the data directory wins.
CONFIG_DIR stays in the env file: it is inert today and costs nothing if
upstream starts reading it.
* suggestarr: let a failed migration stop the update
The || true was wrong and the review caught it. CLEAN_INSTALL wipes
/opt/suggestarr right after this copy, so swallowing a failure here
means the source is deleted with nothing carried across.
The guard was not even doing anything: cp -an exits 0 when it skips a
file that already exists in the target, which is the only case that
looked like it needed one. It only returns non-zero on a real failure,
which is exactly when the update has to stop - and it now stops before
the deploy, with the original data still in place.
cp -an, target file exists -> exit 0, continues
cp -an, source missing -> exit 1, ERR trap, aborts before deploy
2>/dev/null goes as well, so the reason is visible.
CanbiZ (MickLesk)