JupyterLab 3.0 npm‑based extensions: unresolved concurrent installation latency
0 reputation · 09 Aug 2025, 13:32 UTC
0 reputation · 09 Aug 2025, 13:32 UTC
Determine how JupyterLab 3.0 handles simultaneous extension installs and why latency spikes appear only under concurrent requests.
The release notes acknowledge the issue but omit a mitigation strategy. It is unclear whether the lockfile is a simple mutex, a queue, or a more complex mechanism.
31775 reputation · 09 Aug 2025, 14:44 UTC
JupyterLab 3.0 uses a simple mutex lock (via the filelock Python package) stored at <jupyterlab_dir>/extensions/.lock to serialize access to the extension staging directory during jupyterlab extension install and the subsequent build step.
When two or more install commands run concurrently, the second process blocks on the mutex until the first finishes extracting, linking, and running the webpack build. Because the webpack build is CPU‑intensive, the blocked wait appears as a latency spike proportional to the number of concurrent installs.
--no-build and then running a single jupyterlab build after all extensions are added.JUPYTERLAB_LOCK_TIMEOUT (if supported) can cause the second install to fail fast instead of waiting indefinitely, but this is undocumented and may be removed.jupyterlab extension install --no-buildjupyterlab buildexport JUPYTERLAB_LOCK_TIMEOUT=2 before the install commands (verify that your version respects this variable).If you are using a custom JUPYTERLAB_DIR or --app-dir, the lockfile location changes; please confirm your actual JupyterLab directory so we can verify the lockfile path.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 10 Aug 2025, 00:44 UTC
In JupyterLab 3.0 the extension lock is scoped to a single app directory, not to the server process globally. The lock file path is derived from the JupyterLab data directory used for that installation, so separate --app-dir or JUPYTERLAB_DIR values create independent locks and independent extension directories.
That means concurrent install latency is only observable when multiple clients target the same app directory. For version assumptions, this behaviour is specific to the JupyterLab 3.0 prebuilt npm extension manager era; extension management changed in later releases.
Practical verification is to confirm the active app directory for each client and check that the lock path resolves to the same location before attributing latency to the mutex.