style: docs/ polish

docs/advanced/override.md

@@ -30,7 +30,8 @@ numpy = ">=2.0.0"
 This will override the version of `numpy` used by all dependencies in the `dev` feature to be at least `2.0.0`, regardless of what the dependencies specify when the `dev` feature is enabled.
 
 ### Interact with other overrides
-For a specific environment, all the `dependency-overrides` defined in different features will be combined in the order they were when defining the environment.
+
+For a specific environment, all the `dependency-overrides` defined in different features will be combined in the order they were defined.
 
 If the same dependency is overridden multiple times, we'll use the override from the **prior** feature in that environment.
 
@@ -63,4 +64,6 @@ outdated: `numpy == 1.21.0`
 conflict_a: `numpy == 1.21.0` (from `outdated`)
 conflict_b: `numpy == 2.0.0` (from `dev`)
 
-This may contrast with the intuition that all overrides are applied and combined to a result, but it is done this way to avoid conflicts and confusion. Since users are granted fully control over the overrides, it is up to ourselves to choose the right overrides for the environment.
+This may contrast with the intuition that all overrides are applied and combined to a result. It
+is done this way to avoid conflicts and confusion: Since users are granted fully control over the
+overrides, it is up to them to choose the right overrides for an environment.

docs/advanced/pixi_shell.md

@@ -6,13 +6,20 @@ That also means that, instead of `conda deactivate`, it's enough to just exit th
 pixi shell
 ```
 
-On Unix systems the shell command works by creating a "fake" PTY session that will start the shell, and then send a string like `source /tmp/activation-env-12345.sh` to the `stdin` in order to activate the environment. If you would peek under the hood of the the `shell` command, then you would see that this is the first thing executed in the new shell session.
+On Unix systems the shell command works by creating a "fake" PTY session that will start the shell,
+and then send a string like `source /tmp/activation-env-12345.sh` to the `stdin` in order to activate
+the environment. If you would peek under the hood of the the `shell` command, then you
+would see that this is the first thing executed in the new shell session.
 
-The temporary script that we generate ends with `echo "PIXI_ENV_ACTIVATED"` which is used to detect if the environment was activated successfully. If we do not receive this string after three seconds, we will issue a warning to the user.
+The temporary script that we generate ends with `echo "PIXI_ENV_ACTIVATED"` which is used to detect
+if the environment was activated successfully. If we do not receive this string after
+three seconds, we will issue a warning to the user.
 
 ## Issues With Pixi Shell
 
-As explained, `pixi shell` only works well if we execute the activation script _after_ launching shell. Certain commands that are run in the `~/.bashrc` might swallow the activation command, and the environment won't be activated.
+As explained, `pixi shell` only works well if we execute the activation script _after_ launching shell.
+Certain commands that are run in the `~/.bashrc` might swallow the activation command, and the
+environment won't be activated.
 
 For example, if your `~/.bashrc` contains code like the following, `pixi shell` has little chance to succeed:
 

docs/advanced/shebang.md

@@ -1,8 +1,10 @@
 !!!warning "Only on Unix-like systems"
     The following approach only works on Unix-like systems (i.e. Linux and macOS) since Windows does not support shebang lines.
 
-For simple scripts, you can use [`pixi exec`](../reference/cli/pixi/exec.md) to run them directly without needing to take care of installing dependencies or setting up an environment.
-This can be done by adding a [shebang line](https://en.wikipedia.org/wiki/Shebang_(Unix)) at the top of the script, which tells the system how to execute the script.
+For simple scripts, you can use [`pixi exec`](../reference/cli/pixi/exec.md) to run them directly
+without needing to take care of installing dependencies or setting up an environment.
+This can be done by adding a [shebang line](https://en.wikipedia.org/wiki/Shebang_(Unix)) at the top
+of the script, which tells the system how to execute the script.
 Usually, a shebang line starts with `#!/usr/bin/env` followed by the name of the interpreter to use.
 
 Instead of adding an interpreter, you can also just add `pixi exec` at the beginning of the script.

docs/build/dependency_types.md

@@ -1,4 +1,5 @@
-If you add a package to the [dependency table](../reference/pixi_manifest.md#dependencies) of a feature that dependency will be available in all environments that include that feature.
+If you add a package to the [dependency table](../reference/pixi_manifest.md#dependencies) of a feature
+that dependency will be available in all environments that include that feature.
 The dependencies of a package that is being built are a bit more granular.
 Here you can see the three types of dependencies for a simple C++ package.
 

docs/build/dev.md

@@ -1,7 +1,7 @@
 The source packages in the `[dev]` table are not built or installed into the pixi environment.
 The `build-dependencies`, `host-dependencies` and `run-dependencies` of those packages are installed into the pixi environment.
 
-Source dependencies in the `[dependencies]` section are build in an isolated environment and then installed into the workspace.
+Source dependencies in the `[dependencies]` section are build in an isolated directory and then installed into the workspace.
 This means that the `build-` and `host-dependencies` will not be in the pixi environment.
 
 This document explains how you can use the `[dev]` table to depend on the development dependencies of a package.
@@ -10,24 +10,26 @@ This document explains how you can use the `[dev]` table to depend on the develo
 
 Assume a Rust package that you want to develop using Pixi.
 Then we add a `pixi.toml` manifest file:
+
 ```toml title="pixi.toml"
 --8<-- "docs/source_files/pixi_workspaces/pixi_build/dev/pixi.toml:minimal"
 ```
+
 Now you can use Pixi to build the package into a conda package:
 
 ```bash
 pixi build
 ```
 
-But because of the isolated build environments, the development dependencies such as `cargo` are not available in `pixi run`.
+Because of the isolation, the development dependencies such as `cargo` are not available in `pixi run`.
 
-To change that you can add `[dev]` table to the manifest file:
+To change that you can add a `[dev]` table to the manifest file:
 
 ```toml title="pixi.toml"
 --8<-- "docs/source_files/pixi_workspaces/pixi_build/dev/pixi.toml:dev"
 ```
 
-Now when you run `pixi install` the development dependencies will be installed into the pixi environment.
+Now when you run `pixi install` the development dependencies will be installed into the Pixi environment.
 This means that you can now use `cargo` in `pixi run`:
 
 ```bash
@@ -39,6 +41,7 @@ Thus, you can use them during development.
 
 ## Extended example
 This is a full `pixi.toml` example using the `[dev]` table:
+
 ```toml title="pixi.toml"
 --8<-- "docs/source_files/pixi_workspaces/pixi_build/dev/pixi.toml"
 ```

docs/concepts/conda_pypi.md

@@ -19,6 +19,7 @@ The simplified process is as follows:
 
 
 ## Tool Comparison
+
 Here is a non-exhaustive comparison of the features of conda and PyPI ecosystems.
 
 | Feature | Conda | PyPI |

docs/deployment/pixi_pack.md

@@ -1,6 +1,8 @@
 <!-- Keep in sync with https://github.com/quantco/pixi-pack/blob/main/README.md -->
 
-[`pixi-pack`](https://github.com/quantco/pixi-pack) is a simple tool that takes a Pixi environment and packs it into a compressed archive that can be shipped to the target machine. The corresponding `pixi-unpack` tool can be used to unpack the archive and install the environment.
+[`pixi-pack`](https://github.com/quantco/pixi-pack) is a simple tool that takes an environment
+and packs it into a compressed archive that can be shipped to the target machine. The corresponding
+`pixi-unpack` tool can be used to unpack the archive and recreate an environment.
 
 Both tools can be installed via
 
@@ -140,7 +142,8 @@ You can inject additional packages into the environment that are not specified i
 pixi-pack --inject local-package-1.0.0-hbefa133_0.conda pixi.toml
 ```
 
-This can be particularly useful if you build the package itself and want to include the built package in the environment but still want to use `pixi.lock` from the workspace.
+This can be particularly useful if you build the package itself and want to include the built package
+in the environment but still want to use `pixi.lock` from the workspace.
 
 ### PyPi support
 
@@ -202,7 +205,7 @@ Using a cache is particularly useful when:
 
 - Creating multiple packs with overlapping dependencies
 - Working with large packages that take time to download
-- Operating in environments with limited bandwidth
+- Operating on machines with limited bandwidth
 - Running CI/CD pipelines where package caching can significantly improve build times
 
 ### Unpacking Without pixi-pack

docs/first_workspace.md

@@ -1,10 +1,12 @@
 # Making a Pixi workspace
 
 Pixi's biggest strength is its ability to create reproducible, powerful, and flexible workspaces.
-A workspace lives in a directory on your system, and is a collection of Pixi environments that can be used to develop one or many projects in that directory.
-Let's go over the common steps to create a simple Pixi workspace.
+A workspace lives in a directory on your system, and is a collection of environments
+that can be used to develop one or many projects in that directory. Let's go over the common steps
+to create a simple Pixi workspace.
 
 ## Creating a Pixi workspace
+
 To create a new Pixi workspace, you can use the `pixi init` command:
 
 ```shell
@@ -44,10 +46,13 @@ version = "0.1.0"
     Or use the integrated schema support in PyCharm.
 
 ## Managing dependencies
+
 After creating the workspace, you can start adding dependencies.
 Pixi uses the `pixi add` command to add dependencies to a workspace.
-This command will, by default, add the [**conda**](https://prefix.dev/blog/what-is-a-conda-package) dependency to the `pixi.toml`, solve the dependencies, write the [lock file](./workspace/lockfile.md), and install the package in the environment.
-For example, let's add `numpy` and `pytest` to the workspace.
+This command will, by default, add the [**conda**](https://prefix.dev/blog/what-is-a-conda-package)
+dependency to the `pixi.toml`, solve the dependencies, write the [lock file](./workspace/lockfile.md),
+and install the package into an environment. For example, let's add `numpy` and `pytest`
+to the workspace.
 
 ```shell
 pixi add numpy pytest
@@ -85,6 +90,7 @@ httpx = ">=0.28.1,<0.29"
 To learn more about the differences between `conda` and PyPI, see [our Conda & PyPI concept documentation](./concepts/conda_pypi.md).
 
 ## Lock file
+
 Pixi will always create a lock file when the dependencies are solved.
 This file will contain all the exact versions of the workspace's dependencies (and their dependencies).
 This results in a reproducible environment, which you can share with others, and use for testing and deployment.
@@ -118,6 +124,7 @@ packages:
 ```
 
 ## Managing tasks
+
 Pixi has a built-in cross-platform task runner which allows you to define tasks in the manifest.
 Think of tasks as commands (or chains of commands) which you may want to repeat many times over the course of developing a project (for example, running the tests).
 
@@ -140,6 +147,7 @@ You can then run the task using the `pixi run` command:
 ```shell
 pixi run hello
 ```
+
 This will execute the command `echo Hello, World!` in the workspace's default environment.
 
 ??? tip "Do you want to use more powerful features?"
@@ -169,13 +177,18 @@ This will execute the command `echo Hello, World!` in the workspace's default en
     More information about tasks can be found in the [Tasks](./workspace/advanced_tasks.md) section of the documentation.
 
 ## Environments
+
 Pixi always creates an environment for your workspace (the "default" environment),
 which contains your `dependencies` and in which your tasks are run.
 You can also include [multiple environments](./workspace/multi_environment.md) in one workspace.
-These environments are [located](./reference/pixi_configuration.md#detached-environments "Find out how to move this location if required") in the `.pixi/envs` directory in the root of your workspace.
+These environments are [located](./reference/pixi_configuration.md#detached-environments "Find out how to move this location if required")
+in the `.pixi/envs` directory in the root of your workspace.
 
 Using these environments is as simple as running the `pixi run` or `pixi shell` command.
-`pixi run` will execute the remaining input as a command (or a task if the input matches the name of a defined task) in the environment, while `pixi shell` will spawn a new shell session in the environment. Both commands "activate" the environment — learn more at [our environment activation documentation](./workspace/environment.md#activation).
+`pixi run` will execute the remaining input as a command (or a task if the input matches the name of a defined task)
+in the environment, while `pixi shell` will spawn a new shell session in the environment.
+Both commands "activate" the environment — learn more at
+[our environment activation documentation](./workspace/environment.md#activation).
 
 ```shell
 pixi run python -VV

docs/getting_started.md

@@ -19,20 +19,22 @@ Let's go through the basic usage of Pixi.
 - [`pixi clean`](./reference/cli/pixi/clean.md) - remove the environment from your machine
 
 ## Managing global installations
-Pixi can manage global installations of tools and environments.
+
+Pixi can manage global installations of tools in global environments.
 It installs the environments in a central location, so you can use them from anywhere.
 
 - [`pixi global install`](./reference/cli/pixi/global/install.md) - install a package into it's own environment in the global space.
 - [`pixi global uninstall`](./reference/cli/pixi/global/uninstall.md) - uninstall an environment from the global space.
-- [`pixi global add`](./reference/cli/pixi/global/add.md) - add a package to an existing globally installed environment.
+- [`pixi global add`](./reference/cli/pixi/global/add.md) - add a package to an existing global environment.
 - [`pixi global sync`](./reference/cli/pixi/global/sync.md) - sync the globally installed environments with the global manifest, describing all the environments you want to install.
 - [`pixi global edit`](./reference/cli/pixi/global/edit.md) - edit the global manifest.
 - [`pixi global update`](./reference/cli/pixi/global/update.md) - update the global environments
-- [`pixi global list`](./reference/cli/pixi/global/list.md) - list all the installed environments
+- [`pixi global list`](./reference/cli/pixi/global/list.md) - list all the global environments
 
 More information: [Global Tools](./global_tools/introduction.md)
 
 ## Running one-off commands
+
 Pixi can run one-off commands in a specific environment.
 
 - [`pixi exec`](./reference/cli/pixi/exec.md) - run a command in a temporary environment.
@@ -47,9 +49,9 @@ Python 3.13.5 | packaged by conda-forge | (main, Jun 16 2025, 08:24:05) [Clang 1
 Python 3.12.11 | packaged by conda-forge | (main, Jun  4 2025, 14:38:53) [Clang 18.1.8 ]
 ```
 
-## Multiple environments
-Pixi workspaces allow you to manage multiple environments.
-An environment is build out of one or multiple features.
+## Multiple Environments
+
+Pixi workspaces allow you to manage multiple environments. An environment is build out of one or multiple features.
 
 - [`pixi add --feature`](./reference/cli/pixi/add.md#arg---feature) - add a package to a feature
 - [`pixi task add --feature`](./reference/cli/pixi/task/add.md#arg---feature) - add a task to a specific feature
@@ -58,9 +60,10 @@ An environment is build out of one or multiple features.
 - [`pixi shell --environment`](./reference/cli/pixi/shell.md#arg---environment) - activate a specific environment
 - [`pixi list --environment`](./reference/cli/pixi/list.md#arg---environment) - list the dependencies in a specific environment
 
-More information: [Multiple environments](./workspace/multi_environment.md)
+More information: [Multiple Environments](./workspace/multi_environment.md)
 
 ## Tasks
+
 Pixi can run cross-platform tasks using it's built-in task runner.
 This can be a predefined task or any normal executable.
 
@@ -69,6 +72,7 @@ This can be a predefined task or any normal executable.
 
 Tasks can have other tasks as dependencies.
 Here is an example of a more complex task use case
+
 ```toml title="pixi.toml"
 [tasks]
 build = "make build"
@@ -77,9 +81,11 @@ build = "make build"
 cmd = "pytest"
 depends-on = ["build"]
 ```
+
 More information: [Tasks](./workspace/advanced_tasks.md)
 
 ## Multi platform support
+
 Pixi supports multiple platforms out of the box.
 You can specify which platforms your workspace supports and Pixi will ensure that the dependencies are compatible with those platforms.
 
@@ -89,6 +95,7 @@ You can specify which platforms your workspace supports and Pixi will ensure tha
 More information: [Multi platform support](./workspace/multi_platform_configuration.md)
 
 ## Utilities
+
 Pixi comes with a set of utilities to help you debug or manage your setup.
 
 - [`pixi info`](./reference/cli/pixi/info.md) - Show information about the current workspace, and the global setup.

docs/global_tools/introduction.md

@@ -178,11 +178,14 @@ end
 
 ## Adding a Series of Tools at Once
 
-Without specifying an environment, you can add multiple tools at once:
+Without specifying an inastallation environment, you can add multiple tools at once:
+
 ```shell
 pixi global install pixi-pack rattler-build
 ```
+
 This command generates the following entry in the manifest:
+
 ```toml
 [envs.pixi-pack]
 channels = ["conda-forge"]
@@ -194,27 +197,34 @@ channels = ["conda-forge"]
 dependencies = { rattler-build = "*" }
 exposed = { rattler-build = "rattler-build" }
 ```
+
 Creating two separate non-interfering environments, while exposing only the minimum required binaries.
 
 ## Creating a Data Science Sandbox Environment
 
 You can create an environment with multiple tools using the following command:
+
 ```shell
 pixi global install --environment data-science --expose jupyter --expose ipython jupyter numpy pandas matplotlib ipython
 ```
+
 This command generates the following entry in the manifest:
+
 ```toml
 [envs.data-science]
 channels = ["conda-forge"]
 dependencies = { jupyter = "*", ipython = "*" }
 exposed = { jupyter = "jupyter", ipython = "ipython" }
 ```
+
 In this setup, both `jupyter` and `ipython` are exposed from the `data-science` environment, allowing you to run:
+
 ```shell
 > ipython
 # Or
 > jupyter lab
 ```
+
 These commands will be available globally, making it easy to access your preferred tools without switching environments.
 
 ## Install Packages For a Different Platform

docs/global_tools/manifest.md

@@ -23,7 +23,7 @@ dependencies = { python = "3.12.*" } # (1)!
 exposed = { py3 = "python" } # (2)!
 ```
 
-1. Dependencies are the packages that will be installed in the environment. You can specify the version or use a wildcard.
+1. Dependencies are the packages that will be installed into the environment. You can specify the version or use a wildcard.
 2. The exposed binaries are the ones that will be available in the system path. In this case, `python` is exposed under the name `py3`.
 
 ## Manifest locations