Running jupyter notebook and jupyter server give me very similar results and the descriptions are also quite similar.
❯ jupyter notebook -h
The Jupyter HTML Notebook.
This launches a Tornado based HTML Notebook Server that serves up an
HTML5/Javascript Notebook client.
❯ jupyter server -h
The Jupyter Server.
This launches a Tornado-based Jupyter Server.
There are differences like server doesn't load nbextensions but I don't understand why there are two commands that have so much overlap.
For reference, this are the versions of various modules.
❯ jupyter --version
jupyter core : 4.7.1
jupyter-notebook : 6.3.0
qtconsole : 5.0.3
ipython : 7.22.0
ipykernel : 5.3.4
jupyter client : 6.1.12
jupyter lab : 3.0.11
nbconvert : 6.0.7
ipywidgets : 7.6.3
nbformat : 5.1.3
traitlets : 5.0.5
Jupyter Notebook (notebook module) contains both:
the server for notebooks (the backend of the web application that hosts the notebook contents, proxies interaction with kernels, and interacts with the operating system by e.g. opening an internet browser on start; this part is generally written in Python), and
the client (the frontend of the web application, e.g. HTML code, javascript, and some extra REST API points on the server).
However, because there are now multiple clients (frontends) providing different web applications for notebooks:
Jupyter Notebook
JupyterLab
RetroLab
nteract
multiple proprietary clients developed outside of project Jupyter
It made sense to split the server component used by all of these so that e.g. JupyterLab does not have to depend on notebook. This also means that if a fix to the server component is needed, it can be released quickly independent of Jupyter Notebook release cycle (and users of all frontents can benefit immediately).
As a consequence, and to make the break up clean, the old Jupyter Notebook was split into:
jupyter-server - the server which was adapted by JuptyterLab, RetroLab, nteract
nbclassic - the Jupyter Notebook as a jupyter-server extension
This implies changes for users and developers, some already described in "migrate from notebook" docs:
the options specific to server rather than notebook were renamed from c.NotebookApp to c.ServerApp (the options specific to notebook remain c.NotebookApp)
the server-specific configuration is now stored in jupyter_server_config.py rather than jupyter_notebook_config.py (same for .json version)
users should now use jupyter server extension rather than jupyter serverextension (note the extra space!) to list, enable or disable extensions
the server extensions need to place their files in a new location: etc/jupyter/jupyter_server_config.d rather than etc/jupyter/jupyter_notebook_config.d (in practice most extensions that were updated to support jupyter server are now placing files in both locations for backward compatibility with notebook, but this will change in the future)
It is important to note that depending on how you start your jupyter notebook, you will see different servers being used:
jupyter nbclassic (assuming nbclassic is installed) will use the new jupyter-server
jupyter notebook will use the old notebook server
jupyter lab will use new jupyter-server starting with JupyterLab 3.0 unless running on JupyterHub/Binder where it might still be using old notebook server, depending on configuration
This also implies that you may see different extensions when running jupyter notebook vs jupyter nbclassic (depending on whether their developers updated the locations, and whether they decided they want to support the legacy notebook server).
The creation of nbclassic replacement rather than removal of the server code from existing notebook package was meant to ensure backward compatibility, and this is why you still have two copies of the Tornado server (one provided by jupyter notebook and one by jupyter server). To make the situation simpler you could remove notebook and install nblcassic, but given that the transition is in progress you may need to adjust a few things manually. However, this is only a temporary situation, as it is planned that Notebook will be migrated to use jupyter server starting with v7.0.
This might look inconvenient for now, but this step ensures greater maintainability of the core Jupyter infrastructure in the future and will benefit users and system admins greatly later on.
Related
I am currently setting up a Python data-science client for SQL Server Machine Learning Services following this guide: https://learn.microsoft.com/en-us/sql/machine-learning/python/setup-python-client-tools-sql?view=sql-server-ver15
Unfortunately, running Jupyter notebooks for this distribution does not seem to work for me: Typing .\Scripts\jupyter-notebook in the distribution folder, or directly running jupyter-notebook.exe from the Scripts sub-folder does not start Jupyter. In the terminal, the command exits with no ouput.
Afterwards, https://localhost:8889/tree is not reachable as should be the case according to the tutorial above.
Any suggestions? (I already checked https://jupyter-notebook.readthedocs.io/en/stable/troubleshooting.html for solutions). Thank you!
Update: At least .\Scripts\jupyter-console is running, though it is not the same experience.
some cases .\Scripts\jupyter-notebook will not work fine because of the installation issues. As anaconda is having both commercial and enterprise editions, issues will raise.
Instead use the following procedure for cool opening of Jupyter-Notebook in anaconda distribution
Click on Start menu
Type Jupyter
Click on jupter icon which is visible in search results
Jupyter CMD will start running and make it minimized instead closing it. It will open the UI of jupyter notebook in browser.
Jupyter notebook for SQL
Check the documentation link which is available in link which is the configuration of jupyter notebook for SQL.
Document Credit: Rajendra Gupta
https://localhost:8889/tree
I shut down all kernels and close jupyterlab in the browser, but when I open it again it starts a session, and a kernel, for all opened notebooks
I'd followed the code and found that in jupyterlab notebook code the start session function calls (POST /api/sessions) on notebook load if there is not any running kernel for the current notebook. and the API creates a session and also starts a kernel.
I can't find any config for stopping this action in jupyter configs or jupyterlab settings (settings -> advanced settings editor)
You can prevent automatically starting kernels when you open a notebook by running Jupyterlab with the jupyter lab --LabServerApp.notebook_starts_kernel=False flag.
To make the configuration permanent, you can add
c.LabServerApp.notebook_starts_kernel = False to $(jupyter --config-dir)/jupyter_lab_config.py. If this file doesn't exist yet, generate it by running jupyter lab --generate-config.
See this issue comment for more details:
https://github.com/jupyterlab/jupyterlab/issues/12019#issuecomment-1145841583
I would like to setup a system such that it not only runs jupyter notebook on start, but it also starts executing a specific notebook on that jupyter server (running all cells in sequence).
Is this possible? I specifically want to be able to access the notebook web interface and inspect/stop/etc the running notebook at any point.
I know nbconvert can execute a notebook, but it seems to run independently of any existing jupyter servers?
Maybe there is some API I can access so that I can write a shell script to run jupyter notebook and then use the API to open and run a notebook?
I am hoping to use pyRoot, the data analysis framework developed by CERN, by integrating it in a Jupyter notebook. That said, I believe that I did the proper installation of ROOT on my macOS 10.
When I launch the ROOT Jupyter notebook using the following command, it launches properly:
root --notebook
and I get the Jupyter notebook editor. However, whenever I start the notebook by:
import ROOT
The command is kept loading a pop up notification telling me that:
The kernel appears to have died. It will restart automatically.
I am developing applications that use Jupyter notebook and ipywidgets for a GUI frontend to a backend codebase. I have run into issues distributing/installing packages in the normal way, such as:
unexpected differences between required library versions (e.g. pandas)
requirements.txt forcing an update to more recent version of a library when the user maintains and uses their own codebase on an older version of that library.
I think pipenv might be able to solve this problem, but I want to check I have a correct usage before going too far down this path.
Requirements:
the user needs to be able to restart Jupyter Notebook in the same env multiple times, running the program from scratch, until a new version is available.
Users are all on Mac.
Any installation should not alter site-packages etc, have no effect on the python setup any user currently has.
Workflow concept
Development:
Develop within a pipenv environment (I use Pycharm so this is relatively straightforward).
Include jupyter in Pipfile [requires], even though jupyter is not imported anywhere in my source.
Use pipenv install new_package as and when new packages are required by my codebase, and maintain the Pipfile (respecting --dev for testing packages etc).
User installation
Produce a zip file containing source code, setup.py etc plus Pipfile and Pipfile.lock.
User extracts the zip file to a known location on their machine.
In terminal, navigate to the unzipped folder location, and run pipenv install.
Use:
In terminal, navigate to the folder location, and run pipenv shell
Run pipenv run jupyter notebook to reload the env and notebook.
When finished, close out of notebook and run exit to close the env.
Uninstall env and upgrade to newer version
In terminal, navigate to the folder location, and run pipenv --rm.
Download new source zip and follow steps above.
If I've understood, this should ensure anyone can use the distribution in a tightly controlled environment, without making any alterations to their existing python install? Have I overcomplicated things?