mirror of
https://github.com/snapotter-hq/SnapOtter.git
synced 2026-08-03 07:46:42 +02:00
Uninstalling a bundle only deletes its downloaded model weights, never the
shared venv's site-packages, so self-hosters who already hit an AI bundle
conflict (e.g. the scipy ABI strand) have no clean self-service path via
uninstall+reinstall: reinstalling just overlays corrected files on top of
stale ones. Adds POST /api/v1/admin/features/reset, which wipes
/data/ai/{venv,models,pip-cache}, resets installed.json, and reseeds a real
working venv from the image's baked /opt/venv (extracted docker/reseed-ai-venv.sh,
now shared with entrypoint.sh's existing base-venv-upgrade bootstrap instead
of duplicating that logic) -- leaving an empty venv directory here would
make the very next install fail with "spawn .../python3 ENOENT", caught by
testing this live rather than assuming it. Ships with a matching Settings UI
section (inline confirm, same pattern as per-bundle uninstall) and strings
across all 21 locales.
Verified against a real snapotter/snapotter:1.17.2 image migrated to 2.0.0,
with real multi-GB bundles installed (background-removal + OCR): confirmed
the migrated instance's inherited python3.11 venv (2.0.0 itself uses 3.12)
still imports the fixed scipy/numpy/paddleocr correctly, then reset + real
reinstall + actual tool execution (remove-background, verified output image)
all worked end-to-end.
36 lines
1.3 KiB
Bash
36 lines
1.3 KiB
Bash
#!/bin/sh
|
|
set -e
|
|
|
|
# Reseed /data/ai/venv from the image's baked /opt/venv (base packages only:
|
|
# numpy, Pillow, opencv). A raw venv copy is not relocatable -- console
|
|
# scripts and pyvenv.cfg keep the source path -- so rewrite_venv_paths (from
|
|
# entrypoint-lib.sh) patches those after the copy.
|
|
#
|
|
# Used from two places: entrypoint.sh calls this on first boot / when the
|
|
# base venv's stamp changed, and the "Reset AI Environment" admin route
|
|
# (apps/api/src/lib/feature-status.ts resetAiEnvironment()) calls this after
|
|
# wiping /data/ai/venv, so existing installs stuck with a stale/conflicting
|
|
# venv (uninstall alone only removes model weights, never the shared
|
|
# site-packages) have a real, working venv to reinstall bundles into
|
|
# afterward instead of an empty directory with no python3 binary.
|
|
. /usr/local/bin/entrypoint-lib.sh
|
|
|
|
AI_VENV="/data/ai/venv"
|
|
AI_VENV_TMP="/data/ai/venv.bootstrapping"
|
|
|
|
if [ ! -d "/opt/venv" ]; then
|
|
echo "reseed-ai-venv: no base venv at /opt/venv to seed from" >&2
|
|
exit 1
|
|
fi
|
|
|
|
if [ -d "$AI_VENV_TMP" ]; then
|
|
rm -rf "$AI_VENV_TMP"
|
|
fi
|
|
|
|
mkdir -p /data/ai/models /data/ai/pip-cache
|
|
rm -rf "$AI_VENV"
|
|
cp -r /opt/venv "$AI_VENV_TMP"
|
|
mv "$AI_VENV_TMP" "$AI_VENV"
|
|
rewrite_venv_paths "$AI_VENV" "/opt/venv" "$AI_VENV"
|
|
echo "AI venv seeded at $AI_VENV"
|