From 9c044e863ac73c6d0d37eba06c931528a8ac1a23 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 19 Oct 2022 13:33:48 +0000
Subject: [PATCH] [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci
---
 docs/source/reference/config-user-env.md | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/docs/source/reference/config-user-env.md b/docs/source/reference/config-user-env.md
index d32f4d0a..cbf8abd5 100644
--- a/docs/source/reference/config-user-env.md
+++ b/docs/source/reference/config-user-env.md
@@ -23,13 +23,11 @@ This section will focus on user environments, which includes the following:
 
 To make packages available to users, you will typically install packages system-wide or in a shared environment.
 
-
 This installation location should always be in the same environment where
 `jupyterhub-singleuser` itself is installed in, and must be _readable and
 executable_ by your users. If you want your users to be able to install additional
 packages, the installation location must also be _writable_ by your users.
 
-
 If you are using a standard Python installation on your system, use the following command:
 
 ```bash
@@ -78,6 +76,7 @@ with the following substitutions:
 :::
 
 To enable Jupyter notebook's internal idle-shutdown behavior (requires notebook ≥ 5.4), set the following in the `/etc/jupyter/jupyter_server_config.py` file:
+
 ```python
 # shutdown the server after no activity for an hour
 c.ServerApp.shutdown_no_activity_timeout = 60 * 60
@@ -92,12 +91,10 @@ c.MappingKernelManager.cull_interval = 2 * 60
 You may have multiple Jupyter kernels installed and want to make sure that they are available to all of your users. This means installing kernelspecs either system-wide (e.g. in /usr/local/) or in the `sys.prefix` of JupyterHub
 itself.
 
-
 Jupyter kernelspec installation is system-wide by default, but some kernels
 may default to installing kernelspecs in your home directory. These will need
 to be moved system-wide to ensure that they are accessible.
 
-
 To see where your kernelspecs are, you can use the following command:
 
 ```bash
@@ -133,16 +130,13 @@ or a custom prefix such as `/opt/conda`.
 When JupyterHub uses **container-based** Spawners (e.g. KubeSpawner or
 DockerSpawner), the 'system-wide' environment is really the container image used for users.
 
-
 In both cases, you want to _avoid putting configuration in user home
 directories_ because users can change those configuration settings. Also, home directories typically persist once they are created, thereby making it difficult for admins to update later.
 
 ## Named servers
 
-
 By default, in a JupyterHub deployment, each user has one server only.
 
-
 JupyterHub can, however, have multiple servers per user.
 This is mostly useful in deployments where users can configure the environment in which their server will start (e.g. resource requests on an HPC cluster), so that a given user can have multiple configurations running at the same time, without having to stop and restart their own server.
 
@@ -161,11 +155,9 @@ as well as the admin page:
 
 ![named servers on the admin page](../images/named-servers-admin.png)
 
-
 Named servers can be accessed, created, started, stopped, and deleted
 from these pages. Activity tracking is now per server as well.
 
-
 To limit the number of **named server** per user by setting a constant value, use this:
 
 ```python
@@ -192,7 +184,6 @@ If `named_server_limit_per_user` is set to `0`, no limit is enforced.
 
 ## Switching back to the classic notebook
 
-
 By default, the single-user server launches JupyterLab,
 which is based on [Jupyter Server][].
 
@@ -215,7 +206,6 @@ no longer the legacy [Jupyter Notebook][] server.
 JupyterHub prior to 2.0 launched the legacy notebook server (`jupyter notebook`),
 and the Jupyter server could be selected by specifying the following:
 
-
 ```python
 # jupyterhub_config.py
 c.Spawner.cmd = ["jupyter-labhub"]