Choose the notebook server and cell interpreter separately

Wire the interface server and cell interpreter separately

The service uses the application’s dedicated Jupyter environment to start the server. Its kernel specification names the interpreter selected for the project. Server startup and cell execution therefore have separately defined interpreters.

With defaults, both roles can point to the same environment. Selecting an existing virtual environment keeps the interface server in the app environment while cells use the selected interpreter. A package being installed for the application therefore does not establish that a project cell can import it.

IPython’s official guide describes kernels using Python versions or environments different from the one hosting Jupyter. The concrete wiring in this workbench comes from its server arguments and kernel specification. Reading the general documentation does not establish that the connection was exercised on this PC.

Source: IPython documentation, Installing the IPython kernel — kernels for different environments.

Official support for a separately selected kernel environment. No environment was installed or registered during this writing task.

Kernel readiness does not check every work dependency

Project registration records a working root and interpreter path. A separate startup check asks whether the selected Python can import ipykernel. That checks a prerequisite for starting the kernel, not every module imported by the intended notebook.

The default Jupyter setup script installs the declared runtime dependencies. Connecting a project does not automatically read and install an arbitrary requirements file from its folder. Choosing an existing environment still leaves its work-specific packages and versions to be checked there.

Record the interpreter path, kernel readiness and actual notebook dependencies separately. If an import is missing, first identify which Python should supply it. This writing work installed no packages and changed no environment.

The folder locates sources; the kernel provides execution

The launch code uses the project root as the file browser’s starting point and working directory, and adds application and project source paths to Python’s search path. This helps locate sources without copying another environment’s installed packages. The registered root also does not sandbox every operating-system capability of the Python process.

The implementation writes a kernel specification under project-specific data rather than changing the global kernel registry. The server receives that project’s kernel directory and default kernel name. Read the visible name alongside the interpreter arguments to understand which environment it selects.

An existing notebook may remember a different kernel name. The workbench guide tells the operator to select the project kernel in that case. Copying a document or connecting its folder does not by itself align saved kernel metadata with current execution.

Leave environment evidence inside the selected notebook

The following diagnostic cell reads the interpreter path and environment prefix. It was not executed for this article and no actual output is shown. The values may contain private paths, making them evidence for an operator’s internal comparison.

Python documents sys.executable as the interpreter path, which may be empty or None where it cannot be determined. With a virtual environment in effect, sys.prefix points to that environment. These values help identify the interpreter; they do not establish that every required package exists or every cell succeeds.

After identifying the environment, check required imports and persistence between cells as different questions. An expected interpreter path and a variable surviving into the next cell establish different things. The related article concerns another program’s project-isolation work, not a fresh execution test of this workbench.

Source: Python documentation, sys — System-specific parameters and functions, sys.executable and sys.prefix.

Definitions and limits of sys.executable and sys.prefix.

import sys
print(sys.executable)
print(sys.prefix)

Similar notebook views can have different execution contracts

The earlier conversation described code blocks using separate Python processes without carrying a previous cell’s global variables into the next. The current guide distinguishes that block-and-workflow route from the real JupyterLab route. Passing earlier JSON results as inputs is a different contract from keeping variables in a live IPython kernel.

Arranging existing code blocks to resemble a notebook does not change their execution model. The presence of a real JupyterLab path in current source also does not mean that every older block now uses it. Identify which view and execution action are involved.

JupyterLab’s official documentation describes support for existing .ipynb documents. Document-format compatibility and the ability to execute all dependencies required by that document remain separate questions. Locating the file leaves environment checks to do.

Source: JupyterLab documentation, Notebooks — support for existing notebook documents.

Official document-format guidance, not a test of every existing notebook in this workbench.

A ready server still leaves notebook-level checks

The startup code changes the project state to running after a server status response. That establishes JupyterLab server readiness. Cell execution, packages, data paths, saving and reopening still need notebook-level checks.

For this article I compared guides, startup and registration source, declared dependencies and official documentation. I did not import the original program or start its server, kernels or notebooks, and I ran no original regression or build. The diagnostic example receives a syntax check without creating a result from the user’s current environment.

Another workbench can record the server Python, project Python and working root separately, then check the required dependencies and a small cell execution. Reopen the saved document as another check. Leave enough detail for the next operator to select the intended environment and see what still needs verification.