docs: use consistently "Pixi" instead of "pixi"

docs/Community.md

@@ -1,6 +1,6 @@
 # Community
 
-When you want to show your users and contributors that they can use pixi in your repo, you can use the following badge:
+When you want to show your users and contributors that they can use Pixi in your repo, you can use the following badge:
 
 [![Pixi Badge](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/prefix-dev/pixi/main/assets/badge/v0.json)](https://pixi.sh)
 
@@ -49,7 +49,7 @@ When you want to show your users and contributors that they can use pixi in your
   - [pydiverse.transform](https://github.com/pydiverse/pydiverse.transform): Pipe based dataframe manipulation library that can also transform data on SQL databases
 
 - [pixi-pycharm](https://github.com/pavelzw/pixi-pycharm): Conda shim for PyCharm that proxies pixi
-- [pixi-diff-to-markdown](https://github.com/pavelzw/pixi-diff-to-markdown): Generate markdown summaries from pixi update
+- [pixi-diff-to-markdown](https://github.com/pavelzw/pixi-diff-to-markdown): Generate markdown summaries from Pixi update
 - [jiaxiyang/cpp_project_guideline](https://github.com/jiaxiyang/cpp_project_guideline): Guide the way beginners make their c++ projects.
 - [hex-inc/vegafusion](https://github.com/hex-inc/vegafusion): Serverside scaling of Vega and Altair visualizations in Rust, Python, WASM, and Java
 - [pablovela5620/arxiv-researcher](https://github.com/pablovela5620/arxiv-researcher): Summarize PDF's and Arixv papers with Langchain and Nougat 🦉

docs/FAQ.md

@@ -28,5 +28,5 @@ We think it sparks curiosity and fun, if you don't agree, I'm sorry, but you can
 ## Where is `pixi build`
 **TL;DR**: It's coming we promise!
 
-`pixi build` is going to be the subcommand that can generate a conda package out of a pixi project.
+`pixi build` is going to be the subcommand that can generate a conda package out of a Pixi project.
 This requires a solid build tool which we're creating with [`rattler-build`](https://github.com/prefix-dev/rattler-build) which will be used as a library in pixi.

docs/advanced/explain_info_command.md

@@ -33,25 +33,25 @@ default
 
 ## Global info
 
-The first part of the info output is information that is always available and tells you what pixi can read on your machine.
+The first part of the info output is information that is always available and tells you what Pixi can read on your machine.
 
 ### Platform
 
 This defines the platform you're currently on according to pixi.
-If this is incorrect, please file an issue on the [pixi repo](https://github.com/prefix-dev/pixi).
+If this is incorrect, please file an issue on the [Pixi repo](https://github.com/prefix-dev/pixi).
 
 ### Virtual packages
 
-The virtual packages that pixi can find on your machine.
+The virtual packages that Pixi can find on your machine.
 
 In the Conda ecosystem, you can depend on virtual packages.
 These packages aren't real dependencies that are going to be installed, but rather are being used in the solve step to find if a package can be installed on the machine.
 A simple example: When a package depends on Cuda drivers being present on the host machine it can do that by depending on the `__cuda` virtual package.
-In that case, if pixi cannot find the `__cuda` virtual package on your machine the installation will fail.
+In that case, if Pixi cannot find the `__cuda` virtual package on your machine the installation will fail.
 
 ### Cache dir
 
-The directory where pixi stores its cache.
+The directory where Pixi stores its cache.
 Checkout the [cache documentation](../environments/environment.md#caching-packages) for more information.
 
 ### Auth storage
@@ -75,7 +75,7 @@ The path to the [manifest file](../reference/pixi_manifest.md) that describes th
 
 ### Last updated
 
-The last time the lock file was updated, either manually or by pixi itself.
+The last time the lock file was updated, either manually or by Pixi itself.
 
 ## Environment info
 

docs/advanced/installation.md

@@ -30,7 +30,7 @@ Updating is as simple as installing, rerunning the installation script gets you
 ```shell
 pixi self-update
 ```
-Or get a specific pixi version using:
+Or get a specific Pixi version using:
 ```shell
 pixi self-update --version x.y.z
 ```
@@ -42,11 +42,11 @@ pixi self-update --version x.y.z
 
 ## Alternative Installation Methods
 
-Although we recommend installing pixi through the above method we also provide additional installation methods.
+Although we recommend installing Pixi through the above method we also provide additional installation methods.
 
 ### Homebrew
 
-Pixi is available via homebrew. To install pixi via homebrew simply run:
+Pixi is available via homebrew. To install Pixi via homebrew simply run:
 
 ```shell
 brew install pixi
@@ -55,7 +55,7 @@ brew install pixi
 ### Windows Installer
 
 We provide an `msi` installer on [our GitHub releases page](https://github.com/prefix-dev/pixi/releases/latest).
-The installer will download pixi and add it to the path.
+The installer will download Pixi and add it to the path.
 
 ### Winget
 
@@ -66,7 +66,7 @@ winget install prefix-dev.pixi
 ### Install From Source
 
 pixi is 100% written in Rust, and therefore it can be installed, built and tested with cargo.
-To start using pixi from a source build run:
+To start using Pixi from a source build run:
 
 ```shell
 cargo install --locked --git https://github.com/prefix-dev/pixi.git pixi
@@ -94,9 +94,9 @@ its [compile steps](https://github.com/conda/rattler/tree/main#give-it-a-try).
 
     | Variable             | Description                                                                        | Default Value         |
     |----------------------|------------------------------------------------------------------------------------|-----------------------|
-    | `PIXI_VERSION`       | The version of pixi getting installed, can be used to up- or down-grade.           | `latest`              |
+    | `PIXI_VERSION`       | The version of Pixi getting installed, can be used to up- or down-grade.           | `latest`              |
     | `PIXI_HOME`          | The location of the binary folder.                                                 | `$HOME/.pixi`         |
-    | `PIXI_ARCH`          | The architecture the pixi version was built for.                                   | `uname -m`            |
+    | `PIXI_ARCH`          | The architecture the Pixi version was built for.                                   | `uname -m`            |
     | `PIXI_NO_PATH_UPDATE`| If set the `$PATH` will not be updated to add `pixi` to it.                        |                       |
     | `TMP_DIR`            | The temporary directory the script uses to download to and unpack the binary from. | `/tmp`                |
 
@@ -115,7 +115,7 @@ its [compile steps](https://github.com/conda/rattler/tree/main#give-it-a-try).
 
     | Variable         | Environment variable | Description                                                                       | Default Value               |
     |------------------|----------------------|-----------------------------------------------------------------------------------|-----------------------------|
-    | `PixiVersion`    | `PIXI_VERSION`       |The version of pixi getting installed, can be used to up- or down-grade.           | `latest`                    |
+    | `PixiVersion`    | `PIXI_VERSION`       |The version of Pixi getting installed, can be used to up- or down-grade.           | `latest`                    |
     | `PixiHome`       | `PIXI_HOME`          | The location of the installation.                                                 | `$Env:USERPROFILE\.pixi`    |
     | `NoPathUpdate`   |                      | If set, the `$PATH` will not be updated to add `pixi` to it.                      |                             |
 

docs/advanced/shebang.md

@@ -30,7 +30,7 @@ bat my-file.json
     So in total, `pixi exec --spec bat -- bash -e use-bat.sh` is being executed when you run `./use-bat.sh`.
 
 You can also write self-contained python files that ship with their dependencies.
-This example shows a very simple CLI that installs a pixi environment to an arbitrary prefix using [`py-rattler`](https://conda.github.io/rattler/py-rattler) and [`typer`](https://typer.tiangolo.com).
+This example shows a very simple CLI that installs a Pixi environment to an arbitrary prefix using [`py-rattler`](https://conda.github.io/rattler/py-rattler) and [`typer`](https://typer.tiangolo.com).
 
 ```python title="install-pixi-environment-to-prefix.py"
 #!/usr/bin/env -S pixi exec --spec py-rattler>=0.10.0,<0.11 --spec typer>=0.15.0,<0.16 -- python

docs/build/backends.md

@@ -1,6 +1,6 @@
-To decouple the building of a conda package from pixi we provide something what are called build backends.
-These are essentially executables following a specific protocol that is implemented for both pixi and the build backend.
-This also allows for decoupling of the build backend from pixi and it's manifest specification.
+To decouple the building of a conda package from Pixi we provide something what are called build backends.
+These are essentially executables following a specific protocol that is implemented for both Pixi and the build backend.
+This also allows for decoupling of the build backend from Pixi and it's manifest specification.
 
 The backends we are currently developing are available in the following [conda channel](https://prefix.dev/channels/pixi-build-backends).
 And are being developed in the [pixi-build-backends](https://github.com/prefix-dev/pixi-build-backends) repository.
@@ -12,7 +12,7 @@ When looking at the following build-section:
 --8<-- "docs/source_files/pixi_tomls/simple_pixi_build.toml:build-system"
 ```
 
-5. This will allow pixi to install desired backends from the `pixi-build-backends` channel, and any requirements from `conda-forge`. Backends are installed into isolated environments, and will be shared across pixi workspaces.
+5. This will allow Pixi to install desired backends from the `pixi-build-backends` channel, and any requirements from `conda-forge`. Backends are installed into isolated environments, and will be shared across Pixi workspaces.
 
 ### Overriding the Build Backend
 Sometimes you want to override the build backend that is used by pixi. Meaning overriding the backend that is specified in the [`[package.build]`](../reference/pixi_manifest.md#the-build-system). We currently have two environment variables that allow for this:

docs/build/cpp.md

@@ -1,7 +1,7 @@
 # Tutorial: Building a C++ package
 
 This example shows how to build a C++ package with CMake and use it together with `pixi-build`.
-To read more about how building packages work with pixi see the [Getting Started](./getting_started.md) guide.
+To read more about how building packages work with Pixi see the [Getting Started](./getting_started.md) guide.
 
 We'll start off by creating a workspace that use [nanobind](https://github.com/wjakob/nanobind) to build Python bindings.
 That we can also test using pixi.
@@ -45,7 +45,7 @@ Use the following `pixi.toml` file, you can hover over the annotations to see wh
 --8<-- "docs/source_files/pixi_workspaces/pixi_build/cpp/pixi.toml"
 ```
 
-1. Add the **preview** feature `pixi-build` that enables pixi to build the package.
+1. Add the **preview** feature `pixi-build` that enables Pixi to build the package.
 2. These are the workspace dependencies. We add our own package as well as Python so that we can later run our package.
 3. Let's add a task that will run our test
 4. This is where we specify the package name and version.
@@ -93,9 +93,9 @@ This command builds the bindings, installs them and then runs the `test` task.
 
 ## Conclusion
 
-In this tutorial, we created a pixi package using C++.
+In this tutorial, we created a Pixi package using C++.
 It can be used as-is, to upload to a conda channel.
-In another tutorial we will learn how to add multiple pixi packages to the same workspace and let one pixi package use another.
+In another tutorial we will learn how to add multiple Pixi packages to the same workspace and let one Pixi package use another.
 
 Thanks for reading! Happy Coding 🚀
 

docs/build/getting_started.md

@@ -1,7 +1,7 @@
 
 ## Introduction
 
-Next to managing workflows and environments, pixi can also build packages.
+Next to managing workflows and environments, Pixi can also build packages.
 This is useful for the following reasons:
 
 - Building and uploading a package to a conda channel
@@ -22,7 +22,7 @@ The vision is to enable building of packages from source, for any language, on a
 
 ## Setting up the Manifest
 
-This is an overview of the pixi manifest using `pixi-build`.
+This is an overview of the Pixi manifest using `pixi-build`.
 
 ```toml title="pixi.toml"
 --8<-- "docs/source_files/pixi_tomls/simple_pixi_build.toml:full"

docs/build/python.md

@@ -30,7 +30,7 @@ The package will be called `rich_example`, so we will create the following struc
 └── pyproject.toml
 ```
 
-1. This project uses a src-layout, but pixi supports both [flat- and src-layouts](https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/#src-layout-vs-flat-layout).
+1. This project uses a src-layout, but Pixi supports both [flat- and src-layouts](https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/#src-layout-vs-flat-layout).
 
 
 The Python package has a single function `main`.
@@ -57,15 +57,15 @@ The metadata of the Python package is defined in `pyproject.toml`.
 What we have in the moment, constitutes a full Python package.
 It could be uploaded to [PyPI](https://pypi.org/) as-is.
 
-However, we still need a tool to manage our environments and if we want other pixi projects to depend on our tool, we need to include more information.
+However, we still need a tool to manage our environments and if we want other Pixi projects to depend on our tool, we need to include more information.
 We will do exactly that by creating a `pixi.toml`.
 
 !!! note
-    The pixi manifest can be in its own `pixi.toml` file or integrated in `pyproject.toml`
+    The Pixi manifest can be in its own `pixi.toml` file or integrated in `pyproject.toml`
     In this tutorial, we will use `pixi.toml`.
     If you want everything integrated in `pyproject.toml` just copy the content of `pixi.toml` in this tutorial to your `pyproject.toml` and prepend `tool.pixi.` to each table.
 
-Let's initialize a pixi project.
+Let's initialize a Pixi project.
 
 ```
 pixi init --format pixi
@@ -90,10 +90,10 @@ This is the content of the `pixi.toml`:
 ```
 
 1. In `workspace` information is set that is shared across all packages in the workspace.
-2. In `dependencies` you specify all of your pixi packages. Here, this includes only our own package that is defined further below under `package`
+2. In `dependencies` you specify all of your Pixi packages. Here, this includes only our own package that is defined further below under `package`
 3. We define a task that runs the `rich-example-main` executable we defined earlier. You can learn more about tasks in this [section](../environments/advanced_tasks.md)
-4. In `package` we define the actual pixi package. This information will be used when other pixi packages or workspaces depend on our package or when we upload it to a conda channel.
-5. The same way, Python uses build backends to build a Python package, pixi uses build backends to build pixi packages. `pixi-build-python` creates a pixi package out of a Python package.
+4. In `package` we define the actual Pixi package. This information will be used when other Pixi packages or workspaces depend on our package or when we upload it to a conda channel.
+5. The same way, Python uses build backends to build a Python package, Pixi uses build backends to build Pixi packages. `pixi-build-python` creates a Pixi package out of a Python package.
 6. In `package.host-dependencies`, we add Python dependencies that are necessary to build the Python package. By adding them here as well, the dependencies will come from the conda channel rather than PyPI.
 7. In `package.run-dependencies`, we add the Python dependencies needed during runtime.
 
@@ -112,9 +112,9 @@ When we now run `pixi run start`, we get the following output:
 
 ## Conclusion
 
-In this tutorial, we created a pixi package based on Python.
+In this tutorial, we created a Pixi package based on Python.
 It can be used as-is, to upload to a conda channel or to PyPI.
-In another tutorial we will learn how to add multiple pixi packages to the same workspace and let one pixi package use another.
+In another tutorial we will learn how to add multiple Pixi packages to the same workspace and let one Pixi package use another.
 
 Thanks for reading! Happy Coding 🚀
 

docs/build/variants.md

@@ -1,6 +1,6 @@
 # Tutorial: Adding variants
 
-In this tutorial, we will show you how to use variants in order to build a pixi package against different versions of a dependency.
+In this tutorial, we will show you how to use variants in order to build a Pixi package against different versions of a dependency.
 Some might call this functionality, build matrix, build configurations or parameterized builds, in the conda ecosystem this is referred to as a variant.
 
 !!! warning
@@ -9,7 +9,7 @@ Some might call this functionality, build matrix, build configurations or parame
 
 ## Why is this useful?
 
-When we depend on a pixi package, the dependency versions of the package itself are already set.
+When we depend on a Pixi package, the dependency versions of the package itself are already set.
 For example, in the [C++ tutorial](cpp.md) the `python_bindings` package we built depended on Python 3.12.
 Pixi would report a version conflict, if we'd add use both Python 3.11 and `python_bindings` to our workspace.
 By using variants, we can add a set of allowed versions for a specific dependency.
@@ -58,7 +58,7 @@ We do that in `workspace.build-variants`:
 --8<-- "docs/source_files/pixi_workspaces/pixi_build/workspace_variants/pixi.toml:variants"
 ```
 
-If we'd run `pixi install` now, we'd leave it up to pixi whether to use Python 3.11 or 3.12.
+If we'd run `pixi install` now, we'd leave it up to Pixi whether to use Python 3.11 or 3.12.
 In practice, you'll want to create multiple environments specifying a different dependency version.
 In our case this allows us to test our setup against both Python 3.11 and 3.12.
 

docs/build/workspace.md

@@ -1,6 +1,6 @@
 # Tutorial: Integrating multiple packages in a workspace
 
-In this tutorial, we will show you how to integrate multiple pixi packages into a single workspace.
+In this tutorial, we will show you how to integrate multiple Pixi packages into a single workspace.
 
 !!! warning
     `pixi-build` is a preview feature, and will change until it is stabilized.
@@ -38,7 +38,7 @@ The source directory structure now looks like this:
         └── __init__.py
 ```
 
-Within a pixi manifest, you can manage a workspace and/or describe a package.
+Within a Pixi manifest, you can manage a workspace and/or describe a package.
 In the case of `rich_example` we choose to do both, so the only thing we have to add is the dependency on the `python_bindings`.
 
 ```py title="pixi.toml"
@@ -100,7 +100,7 @@ If you run `pixi run start`, the age of each person should now be accurate:
 
 ## Conclusion
 
-In this tutorial, we created a pixi workspace containing two packages.
+In this tutorial, we created a Pixi workspace containing two packages.
 The manifest of `rich_example` describes the workspace as well as the package, with `python_bindings` only the `package` section is used.
 Feel free to add more packages, written in different languages to this workspace!