Context
Two 360-plugin users independently reported that installing it from the marketplace appears to freeze at "Syncing dependencies with uv..." and never recover (alexmgee/lichtfeld-360-plugin#4). I did not hit the freeze myself (my connection clears the downloads quickly), but I reproduced the silent phases locally and traced the mechanism in the installer. Reporting it here because the cause and the fix seem to be in LichtFeld Studio, not in any one plugin.
User Experience
The marketplace card sits on "Syncing dependencies with uv..." with no visible change: no elapsed timer, no download progress, no "still working" indication. On slow or throttled connections that state lasts many minutes to hours, indistinguishable from a hang, so users conclude it is stuck and kill it. The install actually succeeds if left completely alone; this is a missing-feedback problem, not a functional failure.
My Experience
Windows 11 Pro, LichtFeld Studio 0.5.3, bundled uv 0.10.2, bundled Python 3.12.13, installing my plugin 0.2.0 (deps include CUDA PyTorch and a CUDA COLMAP wheel):
- ~35 to 41 s with zero output while uv resolves / revalidates the lockfile (cold cache, valid uv.lock present). uv sync prints nothing until resolution finishes, and for a plugin using a custom index plus a direct-URL wheel that step is network-bound even with a committed lock.
- Then a long silent stretch while large wheels download. uv emits one Downloading torch (2.6GiB) line and nothing more until the file completes. This plugin's payload is ~4.2 GB: the CUDA torch wheel alone is 2.75 GB (download.pytorch.org) and the CUDA pycolmap wheel is 1.2 GB (GitHub releases). On a 50 Mbps link that is 10 to 15 minutes of a motionless label. Where those hosts are throttled it is far longer, and since data keeps trickling, uv's own HTTP timeout never trips. That matches the reporters' experience; one appears to be in a region where download.pytorch.org is slow.
Steps to reproduce
-
Start from a state with no existing venv for the plugin (fresh install, or delete the plugin's .venv).
-
Open Plugin Marketplace and install a plugin whose dependencies are large and/or come from a custom index. The 360 plugin is a clean example.
-
Watch the plugin card.
Location
src/python/lfs_plugins/installer.py, PluginInstaller.install_dependencies(). The marketplace card label is driven off uv's stdout lines, so during any phase where uv is silent the label freezes. There is no heartbeat and no timeout around the child process.
LLM Suggestions
Two small, self-contained changes in installer.py would cover both silent phases:
*Heartbeat: while the uv child produces no output, re-emit the last status line with elapsed time every few seconds, so the label always shows the install is alive.
*Shipped lockfile: when a plugin ships uv.lock, run uv sync --frozen (fall back to a full resolve if the lock cannot be used). Measured to cut time-to-first-output from ~35 s to under 1 s, since --frozen skips the network revalidation and starts downloading immediately.
Related but distinct: #1569 covers a different failure mode of the same plugin-install path (uv.exe missing entirely on source builds). This issue is about missing feedback while a present, working uv downloads large dependencies.
Context
Two 360-plugin users independently reported that installing it from the marketplace appears to freeze at "Syncing dependencies with uv..." and never recover (alexmgee/lichtfeld-360-plugin#4). I did not hit the freeze myself (my connection clears the downloads quickly), but I reproduced the silent phases locally and traced the mechanism in the installer. Reporting it here because the cause and the fix seem to be in LichtFeld Studio, not in any one plugin.
User Experience
The marketplace card sits on "Syncing dependencies with uv..." with no visible change: no elapsed timer, no download progress, no "still working" indication. On slow or throttled connections that state lasts many minutes to hours, indistinguishable from a hang, so users conclude it is stuck and kill it. The install actually succeeds if left completely alone; this is a missing-feedback problem, not a functional failure.
My Experience
Windows 11 Pro, LichtFeld Studio 0.5.3, bundled uv 0.10.2, bundled Python 3.12.13, installing my plugin 0.2.0 (deps include CUDA PyTorch and a CUDA COLMAP wheel):
Steps to reproduce
Start from a state with no existing venv for the plugin (fresh install, or delete the plugin's .venv).
Open Plugin Marketplace and install a plugin whose dependencies are large and/or come from a custom index. The 360 plugin is a clean example.
Watch the plugin card.
Location
src/python/lfs_plugins/installer.py, PluginInstaller.install_dependencies(). The marketplace card label is driven off uv's stdout lines, so during any phase where uv is silent the label freezes. There is no heartbeat and no timeout around the child process.
LLM Suggestions
Two small, self-contained changes in installer.py would cover both silent phases:
*Heartbeat: while the uv child produces no output, re-emit the last status line with elapsed time every few seconds, so the label always shows the install is alive.
*Shipped lockfile: when a plugin ships uv.lock, run uv sync --frozen (fall back to a full resolve if the lock cannot be used). Measured to cut time-to-first-output from ~35 s to under 1 s, since --frozen skips the network revalidation and starts downloading immediately.
Related but distinct: #1569 covers a different failure mode of the same plugin-install path (uv.exe missing entirely on source builds). This issue is about missing feedback while a present, working uv downloads large dependencies.