Lint all files (#489)

* run linter

* fix syntax error after linting

* Update docs/docs/how-tos/nebari-environment-management.md

Co-authored-by: Vinicius D. Cerutti <[email protected]>

---------

Co-authored-by: Vinicius D. Cerutti <[email protected]>

Author: kcpevey

docs/docs/community/decision-making.md

@@ -40,7 +40,6 @@ Learn more in [Gitpod's documentation on decision making][gitpod-rfd].
 
 Minor updates to the codebase and documentation can be discussed in GitHub issues or in pull requests during code review. Contributors are expected to (informally) follow the consent-based decision making philosophy in these discussions.
 
-
 <!-- Reusable links -->
 
 [nebari-team]: /docs/community/team-structure

docs/docs/community/plugins.md

@@ -12,5 +12,5 @@ You can learn to use and create Nebari extensions in the [extension mechanism do
 
 The following community-developed extensions are recognized and verified by the Nebari development team.
 
-* [nebari-mlflow-aws](https://github.com/MetroStar/nebari-mlflow-aws)
-* [nebari-label-studio](https://github.com/MetroStar/nebari-label-studio)
+- [nebari-mlflow-aws](https://github.com/MetroStar/nebari-mlflow-aws)
+- [nebari-label-studio](https://github.com/MetroStar/nebari-label-studio)

docs/docs/community/team-structure.md

@@ -57,9 +57,9 @@ Nebari follows a nomination process to add new team members[^2], as detailed in
 
 [^2]: All except the [Emeritus core](#emeritus-core) team are decided through nominations.
 
-| Team        | Requirements for nomination                                                                                         | Nominators                                                          | Approvers                                                                                                               |
-| ----------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
-| Triage      | Engage with (create or comment on) one or more issue/PR/discussion in [`nebari-dev`](https://github.com/nebari-dev) | Any community member (including self)                                        | Any Core team member                                                                                                    |
-| Contributor | Two or more [contributions](./#how-to-contribute) to Nebari with intention to continue contributing regularly                                          | Any community member (including self)                                    | Any Core team member                                                                                |
-| Core        | [Contributors team](#contributors) member with a record of regular, valuable, and high-quality contributions to Nebari for at least one month  | Any community member (including self) and one Core team member | Core team makes a [consent-based decision](https://www.sociocracyforall.org/consent-decision-making/) |
-| Conduct     | Member of the Contributor or Core Team with adequate training to handle CoC reports         | Any community member (including self)                                    | Core team makes a [consent-based decision](https://www.sociocracyforall.org/consent-decision-making/)                                                                                 |
+| Team        | Requirements for nomination                                                                                                                   | Nominators                                                     | Approvers                                                                                             |
+| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
+| Triage      | Engage with (create or comment on) one or more issue/PR/discussion in [`nebari-dev`](https://github.com/nebari-dev)                           | Any community member (including self)                          | Any Core team member                                                                                  |
+| Contributor | Two or more [contributions](./#how-to-contribute) to Nebari with intention to continue contributing regularly                                 | Any community member (including self)                          | Any Core team member                                                                                  |
+| Core        | [Contributors team](#contributors) member with a record of regular, valuable, and high-quality contributions to Nebari for at least one month | Any community member (including self) and one Core team member | Core team makes a [consent-based decision](https://www.sociocracyforall.org/consent-decision-making/) |
+| Conduct     | Member of the Contributor or Core Team with adequate training to handle CoC reports                                                           | Any community member (including self)                          | Core team makes a [consent-based decision](https://www.sociocracyforall.org/consent-decision-making/) |

docs/docs/explanations/advanced-configuration.md

@@ -13,7 +13,6 @@ In the "How to deploy Nebari" pages of our docs we covered how you can auto-gene
 After first initializing a project, you can find the configuration file, `nebari-config.yaml`, in your project directory.
 This file is a `YAML` file that exports sets of parameters used by Nebari to deploy and redeploy changes to your infrastructure.
 
-
 <details>
 <summary>Complete configuration example.</summary>
 
@@ -238,20 +237,17 @@ conda_store:
 
 The `nebari-config.yaml` file can be split into several sections.
 
-The first section is the version of Nebari you wish to run. 
-
-
+The first section is the version of Nebari you wish to run.
 
 ```yaml
 ### Nebari version ###
 nebari_version: 2023.7.2
 ```
 
 :::note
-You will get a validation error if the version of `nebari` used from the command line is different from the one in the `nebari-config.yaml`. 
+You will get a validation error if the version of `nebari` used from the command line is different from the one in the `nebari-config.yaml`.
 :::
 
-
 The next section relates to Nebari's inner mechanics for the initial deployment and is the most important section of the configuration file,
 because the following parameters are heavily propagated throughout all infrastructure components.
 
@@ -283,11 +279,12 @@ domain: demo.nebari.dev
 
 ### Continuous integration and continuous deployment
 
-Nebari uses [infrastructure-as-code](https://en.wikipedia.org/wiki/Infrastructure_as_code) to maintain a description of the deployed infrastructure in source control.  By using a git repository with CI/CD configured, teams can more quickly modify their deployment, empowering developers and data scientists to request the changes and have them approved by an administrator.
+Nebari uses [infrastructure-as-code](https://en.wikipedia.org/wiki/Infrastructure_as_code) to maintain a description of the deployed infrastructure in source control. By using a git repository with CI/CD configured, teams can more quickly modify their deployment, empowering developers and data scientists to request the changes and have them approved by an administrator.
 
-When a `ci_cd` section is configured within your `nebari-config.yaml`, the first `nebari deploy` command will create all related files that describe a [CI/CD](https://about.gitlab.com/topics/ci-cd/) process.  These pipelines will then be responsible for redeploying Nebari as changes are made to a specified branch.  (Alternatively, an administrator can use `nebari render` to generate the necessary files as if running a dry-run.)  Currently, Nebari can generate CI/CD for [GitHub Actions](https://docs.github.com/en/actions) and [GitLab CI](https://docs.gitlab.com/ee/ci/).
+When a `ci_cd` section is configured within your `nebari-config.yaml`, the first `nebari deploy` command will create all related files that describe a [CI/CD](https://about.gitlab.com/topics/ci-cd/) process. These pipelines will then be responsible for redeploying Nebari as changes are made to a specified branch. (Alternatively, an administrator can use `nebari render` to generate the necessary files as if running a dry-run.) Currently, Nebari can generate CI/CD for [GitHub Actions](https://docs.github.com/en/actions) and [GitLab CI](https://docs.gitlab.com/ee/ci/).
 
 Below is an example `ci_cd` section in a `nebari-config.yaml` file.
+
 ```yaml
 ### Continuous integration ###
 ci_cd:
@@ -312,15 +309,14 @@ ci_cd:
 
 The CI/CD workflow that is best for you will depend on your organization, but the following tenets will be appropriate for most situations.
 
-* You will want to have an upstream Git repository configured - we recommend either GitHub or GitLab since we support generating CI/CD jobs for these products.
-* The branch that triggers deployment (typically `main`, but you can set other ones in Nebari config's `ci_cd.branch`) should be protected so that only sys admins can commit or approve pull (or merge) requests into it.
-* CI/CD variables must be set in your repository so the pipeline can access your cloud (see Note below)
-* Non-admin users who have write access to the repository's non-protected branches may create their own branch off of `main`, locally make changes to the `nebari-config.yaml` and other files, and then push that branch to the origin and propose they be deployed via a Pull Request.
-* Advanced Nebari users may also want to add a step in their deployment flow that includes a `nebari render` so that the administrator may preview the resulting diffs to IaC and/or CI/CD files before `nebari deploy` is executed.
-
+- You will want to have an upstream Git repository configured - we recommend either GitHub or GitLab since we support generating CI/CD jobs for these products.
+- The branch that triggers deployment (typically `main`, but you can set other ones in Nebari config's `ci_cd.branch`) should be protected so that only sys admins can commit or approve pull (or merge) requests into it.
+- CI/CD variables must be set in your repository so the pipeline can access your cloud (see Note below)
+- Non-admin users who have write access to the repository's non-protected branches may create their own branch off of `main`, locally make changes to the `nebari-config.yaml` and other files, and then push that branch to the origin and propose they be deployed via a Pull Request.
+- Advanced Nebari users may also want to add a step in their deployment flow that includes a `nebari render` so that the administrator may preview the resulting diffs to IaC and/or CI/CD files before `nebari deploy` is executed.
 
 :::note
-In order for your CI/CD pipeline to be able to deploy changes into your Nebari cloud hosting provider, you must set the appropriate authentication environment variables for your GitLab or GitHub CI/CD execution environment.  See the Authentication section for deploing to [AWS](https://www.nebari.dev/docs/how-tos/nebari-aws/#authentication), [Azure](https://www.nebari.dev/docs/how-tos/nebari-azure#authentication), [GCP](https://www.nebari.dev/docs/how-tos/nebari-gcp/#authentication), or [Digital Ocean](https://www.nebari.dev/docs/how-tos/nebari-do/#authentication) for Nebari's required variables.  Guidance on how to set these for your repository/project can be found in the documentation for [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/variables) and [GitLab CI/CD](https://docs.gitlab.com/ee/ci/variables/).
+In order for your CI/CD pipeline to be able to deploy changes into your Nebari cloud hosting provider, you must set the appropriate authentication environment variables for your GitLab or GitHub CI/CD execution environment. See the Authentication section for deploing to [AWS](https://www.nebari.dev/docs/how-tos/nebari-aws/#authentication), [Azure](https://www.nebari.dev/docs/how-tos/nebari-azure#authentication), [GCP](https://www.nebari.dev/docs/how-tos/nebari-gcp/#authentication), or [Digital Ocean](https://www.nebari.dev/docs/how-tos/nebari-do/#authentication) for Nebari's required variables. Guidance on how to set these for your repository/project can be found in the documentation for [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/variables) and [GitLab CI/CD](https://docs.gitlab.com/ee/ci/variables/).
 :::
 
 ### Certificates
@@ -376,11 +372,10 @@ In general you should use the production server, as seen above.
 You can also generate the above configuration automatically by using the `--ssl-cert-email <your-email-address>` flag when you run `nebari init` to initialize your project.
 :::
 
-
-Let's Encrypt heavily rate limits their production endpoint.  In order to avoid throttling, Nebari's traefik deployments will store retrieved certificates for the duration of their validity in a mounted PVC at a default location `/mnt/acme-certificates/acme.json`.
+Let's Encrypt heavily rate limits their production endpoint. In order to avoid throttling, Nebari's traefik deployments will store retrieved certificates for the duration of their validity in a mounted PVC at a default location `/mnt/acme-certificates/acme.json`.
 
 :::note
-In order to refresh the certificate before it is invalidated, you will need to delete the `acme.json` file then restart the Traefik deployment by deleting the existing pod and letting a new one spin up.  This may be necessary if you change the domain name of your Nebari deployment.
+In order to refresh the certificate before it is invalidated, you will need to delete the `acme.json` file then restart the Traefik deployment by deleting the existing pod and letting a new one spin up. This may be necessary if you change the domain name of your Nebari deployment.
 :::
 
   </TabItem>
@@ -425,4 +420,4 @@ Learn to configure more aspects of your Nebari deployment with the following top
 - [JupyterLab and Dask profile configuration](./advanced-profiles-settings.md)
 - [Customize JuputerHub theme](./advanced-custom-settings.md)
 - [Environment configuration](./advanced-env-configuration.md)
-- [Custom settings and overrides](./advanced-custom-settings.md)
+- [Custom settings and overrides](./advanced-custom-settings.md)

docs/docs/faq.md

@@ -31,8 +31,9 @@ There are drop-in replacements for `distributed`, `dask`, and `dask-gateway` wit
 ## What packages are needed in your environment to create a dashboard?
 
 When deploying an app with JHub App Launcher, you need to have the following in your environment:
+
 - `jhub-apps` package
-- packages corresponding  to the dashboard framework (for example, `panel`, `gradio`, etc.)
+- packages corresponding to the dashboard framework (for example, `panel`, `gradio`, etc.)
 - any other libraries required for the analysis in the dashboard creation script/notebook
 
 ## How can I install a package locally? Will this package be available to Dask workers?
@@ -163,6 +164,7 @@ Nebari automatically shuts down servers when users are idle, as described in Neb
 :::note
 Until this issue is addressed, we recommend manually shutting down your VS Code server when it is not in use.
 :::
+
 <!-- Internal links -->
 
 [dask-tutorial]: tutorials/using_dask.md

docs/docs/get-started/installing-nebari.md

@@ -22,7 +22,8 @@ Nebari heavily depends on [Terraform](https://www.terraform.io/) and Python. The
 - To install conda, visit the [official conda documentation](https://docs.conda.io/projects/conda/en/latest/user-guide/install/index.html), or if you prefer, visit the [mamba installation documentation](https://github.com/mamba-org/mamba#installation)
 
 ## How to install the Nebari Package
-*See [Environment Management][environment-management] for best practices for using `conda` and `pip` to control your deployment environment.*
+
+_See [Environment Management][environment-management] for best practices for using `conda` and `pip` to control your deployment environment._
 
 There are currently two ways to install the Nebari CLI:
 
@@ -45,12 +46,13 @@ There are currently two ways to install the Nebari CLI:
    ```
 
 :::note
-The version of Nebari in your `nebari-config.yaml` must match your currently installed Nebari package version; otherwise, a warning will be raised when attempting to deploy.  See [Upgrading Nebari][nebari-upgrade] for techniques for upgrading your Nebari CLI or safely updating your older config file to match your Nebari package version.
+The version of Nebari in your `nebari-config.yaml` must match your currently installed Nebari package version; otherwise, a warning will be raised when attempting to deploy. See [Upgrading Nebari][nebari-upgrade] for techniques for upgrading your Nebari CLI or safely updating your older config file to match your Nebari package version.
 :::
 
 :::note
-The Nebari CLI will auto-detect and then deploy any [Nebari Extensions][nebari-extension-system] that are installed in your Python environment, and extensions once deployed cannot be uninstalled.  For this reason, we recommend creating a [unique environment][environment-management] for each Nebari deployment, especially when managing multiple deployments with extensions.
+The Nebari CLI will auto-detect and then deploy any [Nebari Extensions][nebari-extension-system] that are installed in your Python environment, and extensions once deployed cannot be uninstalled. For this reason, we recommend creating a [unique environment][environment-management] for each Nebari deployment, especially when managing multiple deployments with extensions.
 :::
+
 ## Verify installation
 
 You can verify that the Nebari package is properly installed and you can execute the client commands by running:

docs/docs/get-started/quickstart.md

@@ -121,14 +121,14 @@ nebari init azure --project projectname \
 
 ## Validate (optional)
 
-After creating the `nebari-config.yaml` file, you can customize it. The Nebari package uses Pydantic for schema validation.  To ensure your customizations are valid, run:
+After creating the `nebari-config.yaml` file, you can customize it. The Nebari package uses Pydantic for schema validation. To ensure your customizations are valid, run:
 
 ```bash
 nebari validate -c nebari-config.yaml
 ```
 
 :::note
-Extensions built using the [Nebari Extension System][nebari-extension-system] may extend the Nebari schema.  If you are intending to use an extension and `nebari validate` returns an error `Extra inputs are not permitted`, ensure that the the correct versions of the extensions you intend to use are installed in your active Python environment.
+Extensions built using the [Nebari Extension System][nebari-extension-system] may extend the Nebari schema. If you are intending to use an extension and `nebari validate` returns an error `Extra inputs are not permitted`, ensure that the the correct versions of the extensions you intend to use are installed in your active Python environment.
 :::
 
 :::note
@@ -143,13 +143,12 @@ You can generate the (Terraform) deployment workflow scripts with:
 nebari render -c nebari-config.yaml
 ```
 
-This is the actual step that loads the stage classes/models and generates physical IaC files based on your Nebari config file and installed package versions.  It is not necessary to manually run a render to deploy.  However, it can be useful (especially if you use a GitOps workflow with GitHub Actions or GitLab CI/CD) to review the effects of config files changes on the resulting IaC before deploying.
+This is the actual step that loads the stage classes/models and generates physical IaC files based on your Nebari config file and installed package versions. It is not necessary to manually run a render to deploy. However, it can be useful (especially if you use a GitOps workflow with GitHub Actions or GitLab CI/CD) to review the effects of config files changes on the resulting IaC before deploying.
 
 :::note
 This command is automatically run when you `deploy`.
 :::
 
-
 ## Deploy
 
 <Tabs>