diff --git a/docs/Community.md b/docs/Community.md index 5b76ef3cf5..5352322cce 100644 --- a/docs/Community.md +++ b/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 🦉 diff --git a/docs/FAQ.md b/docs/FAQ.md index 1a5ddd3944..a11ac9b41e 100644 --- a/docs/FAQ.md +++ b/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. diff --git a/docs/advanced/explain_info_command.md b/docs/advanced/explain_info_command.md index 169011d9b2..36ed3955d4 100644 --- a/docs/advanced/explain_info_command.md +++ b/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 diff --git a/docs/advanced/installation.md b/docs/advanced/installation.md index a753e59085..c9297ed7cf 100644 --- a/docs/advanced/installation.md +++ b/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. | | diff --git a/docs/advanced/shebang.md b/docs/advanced/shebang.md index 4361585f6e..b028a445cd 100644 --- a/docs/advanced/shebang.md +++ b/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 diff --git a/docs/build/backends.md b/docs/build/backends.md index 9d4508deea..6efa4ebf57 100644 --- a/docs/build/backends.md +++ b/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: diff --git a/docs/build/cpp.md b/docs/build/cpp.md index 03d58ca0a0..197281f635 100644 --- a/docs/build/cpp.md +++ b/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 🚀 diff --git a/docs/build/getting_started.md b/docs/build/getting_started.md index 880752ef5c..4f5743f747 100644 --- a/docs/build/getting_started.md +++ b/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" diff --git a/docs/build/python.md b/docs/build/python.md index 090f473849..307327b3c4 100644 --- a/docs/build/python.md +++ b/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 🚀 diff --git a/docs/build/variants.md b/docs/build/variants.md index 89fc06e84a..23bf413890 100644 --- a/docs/build/variants.md +++ b/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. diff --git a/docs/build/workspace.md b/docs/build/workspace.md index c18d48ec90..c0a0176d24 100644 --- a/docs/build/workspace.md +++ b/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! diff --git a/docs/deployment/authentication.md b/docs/deployment/authentication.md index 816fa040a9..257dd2a0ad 100644 --- a/docs/deployment/authentication.md +++ b/docs/deployment/authentication.md @@ -1,5 +1,5 @@ -You can authenticate pixi with a server like prefix.dev, a private quetz instance or anaconda.org. +You can authenticate Pixi with a server like prefix.dev, a private quetz instance or anaconda.org. Different servers use different authentication methods. In this documentation page, we detail how you can authenticate against the different servers and where the authentication information is stored. @@ -64,19 +64,19 @@ pixi auth login s3://my-bucket --s3-access-key-id --s3-secret-ac !!!note S3 authentication is also supported through AWS's typical `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables, see the [S3 section](s3.md) for more details. -## Where does pixi store the authentication information? +## Where does Pixi store the authentication information? -The storage location for the authentication information is system-dependent. By default, pixi tries to use the keychain to store this sensitive information securely on your machine. +The storage location for the authentication information is system-dependent. By default, Pixi tries to use the keychain to store this sensitive information securely on your machine. -On Windows, the credentials are stored in the "credentials manager". Searching for `rattler` (the underlying library pixi uses) you should find any credentials stored by pixi (or other rattler-based programs). +On Windows, the credentials are stored in the "credentials manager". Searching for `rattler` (the underlying library Pixi uses) you should find any credentials stored by Pixi (or other rattler-based programs). -On macOS, the passwords are stored in the keychain. To access the password, you can use the `Keychain Access` program that comes pre-installed on macOS. Searching for `rattler` (the underlying library pixi uses) you should find any credentials stored by pixi (or other rattler-based programs). +On macOS, the passwords are stored in the keychain. To access the password, you can use the `Keychain Access` program that comes pre-installed on macOS. Searching for `rattler` (the underlying library Pixi uses) you should find any credentials stored by Pixi (or other rattler-based programs). -On Linux, one can use `GNOME Keyring` (or just Keyring) to access credentials that are securely stored by `libsecret`. Searching for `rattler` should list all the credentials stored by pixi and other rattler-based programs. +On Linux, one can use `GNOME Keyring` (or just Keyring) to access credentials that are securely stored by `libsecret`. Searching for `rattler` should list all the credentials stored by Pixi and other rattler-based programs. ## Fallback storage -If you run on a server with none of the aforementioned keychains available, then pixi falls back to store the credentials in an _insecure_ JSON file. +If you run on a server with none of the aforementioned keychains available, then Pixi falls back to store the credentials in an _insecure_ JSON file. This JSON file is located at `~/.rattler/credentials.json` and contains the credentials. ## Override the authentication storage @@ -136,11 +136,11 @@ We want to add more methods in the future, so if you have a specific method you ### Keyring authentication -Currently, pixi supports the uv method of authentication through the python [keyring](https://pypi.org/project/keyring/) library. +Currently, Pixi supports the uv method of authentication through the python [keyring](https://pypi.org/project/keyring/) library. #### Installing keyring -To install keyring you can use pixi global install: +To install keyring you can use `pixi global install`: === "Basic Auth" ```shell @@ -171,7 +171,7 @@ For other registries, you will need to adapt these instructions to add the right # prompt will appear for your password ``` - Add the following configuration to your pixi manifest, making sure to include `your_username@` in the URL of the registry: + Add the following configuration to your Pixi manifest, making sure to include `your_username@` in the URL of the registry: ```toml [pypi-options] @@ -179,7 +179,7 @@ For other registries, you will need to adapt these instructions to add the right ``` === "Google Artifact Registry" - After making sure you are logged in, for instance by running `gcloud auth login`, add the following configuration to your pixi manifest: + After making sure you are logged in, for instance by running `gcloud auth login`, add the following configuration to your Pixi manifest: ```toml [pypi-options] @@ -194,7 +194,7 @@ For other registries, you will need to adapt these instructions to add the right ``` === "Azure DevOps Artifacts" - After following the [`keyring.artifacts` instructions](https://github.com/jslorrma/keyrings.artifacts?tab=readme-ov-file#usage) and making sure that keyring works correctly, add the following configuration to your pixi manifest: + After following the [`keyring.artifacts` instructions](https://github.com/jslorrma/keyrings.artifacts?tab=readme-ov-file#usage) and making sure that keyring works correctly, add the following configuration to your Pixi manifest: ```toml [pypi-options] @@ -202,7 +202,7 @@ For other registries, you will need to adapt these instructions to add the right ``` === "AWS CodeArtifact" - Ensure you are logged in e.g via `aws sso login` and add the following configuration to your pixi manifest: + Ensure you are logged in e.g via `aws sso login` and add the following configuration to your Pixi manifest: ```toml [pypi-options] diff --git a/docs/deployment/container.md b/docs/deployment/container.md index 3a048fc8e3..7e5593e110 100644 --- a/docs/deployment/container.md +++ b/docs/deployment/container.md @@ -1,10 +1,10 @@ -# Bringing pixi to production +# Bringing Pixi to production -One way to bring a pixi package into production is to containerize it using tools like Docker or Podman. +One way to bring a Pixi package into production is to containerize it using tools like Docker or Podman. -We provide a simple docker image at [`pixi-docker`](https://github.com/prefix-dev/pixi-docker) that contains the pixi executable on top of different base images. +We provide a simple docker image at [`pixi-docker`](https://github.com/prefix-dev/pixi-docker) that contains the Pixi executable on top of different base images. The images are available on [ghcr.io/prefix-dev/pixi](https://ghcr.io/prefix-dev/pixi). @@ -21,8 +21,8 @@ There are different tags for different base images available: ### Example usage -The following example uses the pixi docker image as a base image for a multi-stage build. -It also makes use of `pixi shell-hook` to not rely on pixi being installed in the production container. +The following example uses the Pixi docker image as a base image for a multi-stage build. +It also makes use of `pixi shell-hook` to not rely on Pixi being installed in the production container. !!!tip "More examples" For more examples, take a look at [pavelzw/pixi-docker-example](https://github.com/pavelzw/pixi-docker-example). diff --git a/docs/deployment/pixi_pack.md b/docs/deployment/pixi_pack.md index b109e8a93c..602d3d683c 100644 --- a/docs/deployment/pixi_pack.md +++ b/docs/deployment/pixi_pack.md @@ -1,7 +1,7 @@ # Pixi Pack -[`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. +[`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. It can be installed via @@ -11,7 +11,7 @@ pixi global install pixi-pack Or by downloading our pre-built binaries from the [releases page](https://github.com/quantco/pixi-pack/releases). -Instead of installing pixi-pack globally, you can also use pixi exec to run `pixi-pack` in a temporary environment: +Instead of installing pixi-pack globally, you can also use Pixi exec to run `pixi-pack` in a temporary environment: ```bash pixi exec pixi-pack pack diff --git a/docs/deployment/s3.md b/docs/deployment/s3.md index c46dc2b096..5e5fa63691 100644 --- a/docs/deployment/s3.md +++ b/docs/deployment/s3.md @@ -33,7 +33,7 @@ Pixi supports two ways to configure access to your S3 bucket: ## Using AWS configuration -You can specify `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` in your environment variables for pixi to use them. +You can specify `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` in your environment variables for Pixi to use them. You can also specify `AWS_CONFIG_FILE` and `AWS_PROFILE` to use a custom AWS configuration file and profile. @@ -106,7 +106,7 @@ $ pixi search my-private-package # ... ``` -You can also specify the `s3-options` in your [pixi configuration](../reference/pixi_configuration.md). +You can also specify the `s3-options` in your [Pixi configuration](../reference/pixi_configuration.md). ```toml title="Global configuration" [s3-options.my-bucket] @@ -182,7 +182,7 @@ Cloudflare R2 also supports public buckets through a Cloudflare-managed `r2.dev` ## S3-compatible storage Many other cloud providers offer S3-compatible storage APIs. -You can use them with pixi by specifying the `s3-options` in your manifest file. +You can use them with Pixi by specifying the `s3-options` in your manifest file. ### MinIO @@ -219,7 +219,7 @@ force-path-style = true ### Google Cloud Storage -Note pixi also supports `gcs://` URLs. +Note Pixi also supports `gcs://` URLs. ```toml title="pixi.toml" endpoint-url = "https://storage.googleapis.com" diff --git a/docs/environments/advanced_tasks.md b/docs/environments/advanced_tasks.md index d2d9469569..83cc477170 100644 --- a/docs/environments/advanced_tasks.md +++ b/docs/environments/advanced_tasks.md @@ -1,7 +1,7 @@ When building a package, you often have to do more than just run the code. Steps like formatting, linting, compiling, testing, benchmarking, etc. are often part of a workspace. -With pixi tasks, this should become much easier to do. +With Pixi tasks, this should become much easier to do. Here are some quick examples @@ -104,9 +104,9 @@ pixi run style Pixi tasks support the definition of a working directory. `cwd`" stands for Current Working Directory. -The directory is relative to the pixi package root, where the `pixi.toml` file is located. +The directory is relative to the Pixi package root, where the `pixi.toml` file is located. -Consider a pixi workspace structured as follows: +Consider a Pixi workspace structured as follows: ```shell ├── pixi.toml @@ -129,9 +129,9 @@ bar = { cmd = "python bar.py", cwd = "scripts" } ## Caching -When you specify `inputs` and/or `outputs` to a task, pixi will reuse the result of the task. +When you specify `inputs` and/or `outputs` to a task, Pixi will reuse the result of the task. -For the cache, pixi checks that the following are true: +For the cache, Pixi checks that the following are true: - No package in the environment has changed. - The selected inputs and outputs are the same as the last time the task was @@ -139,7 +139,7 @@ For the cache, pixi checks that the following are true: compare them to the last time the task was run. - The command is the same as the last time the task was run. -If all of these conditions are met, pixi will not run the task again and instead use the existing result. +If all of these conditions are met, Pixi will not run the task again and instead use the existing result. Inputs and outputs can be specified as globs, which will be expanded to all matching files. @@ -191,8 +191,8 @@ These variables are not shared over tasks, so you need to define these for every This will output `/tmp/path:/usr/bin:/bin` instead of the original `/usr/bin:/bin`. ## Clean environment -You can make sure the environment of a task is "pixi only". -Here pixi will only include the minimal required environment variables for your platform to run the command in. +You can make sure the environment of a task is "Pixi only". +Here Pixi will only include the minimal required environment variables for your platform to run the command in. The environment will contain all variables set by the conda environment like `"CONDA_PREFIX"`. It will however include some default values from the shell, like: `"DISPLAY"`, `"LC_ALL"`, `"LC_TIME"`, `"LC_NUMERIC"`, `"LC_MEASUREMENT"`, `"SHELL"`, `"USER"`, `"USERNAME"`, `"LOGNAME"`, `"HOME"`, `"HOSTNAME"`,`"TMPDIR"`, `"XPC_SERVICE_NAME"`, `"XPC_FLAGS"` @@ -211,7 +211,7 @@ This setting can also be set from the command line with `pixi run --clean-env TA ## Our task runner: deno_task_shell -To support the different OS's (Windows, OSX and Linux), pixi integrates a shell that can run on all of them. +To support the different OS's (Windows, OSX and Linux), Pixi integrates a shell that can run on all of them. This is [`deno_task_shell`](https://deno.land/manual@v1.35.0/tools/task_runner#built-in-commands). The task shell is a limited implementation of a bourne-shell interface. diff --git a/docs/environments/environment.md b/docs/environments/environment.md index 2267d48c04..0d003e14ab 100644 --- a/docs/environments/environment.md +++ b/docs/environments/environment.md @@ -6,7 +6,7 @@ This document explains what an environment looks like and how to use it. ## Structure -A pixi environment is located in the `.pixi/envs` directory of the workspace by default. +A Pixi environment is located in the `.pixi/envs` directory of the workspace by default. This keeps your machine and your workspace clean and isolated from each other, and makes it easy to clean up after a workspace is done. While this structure is generally recommended, environments can also be stored outside of workspace directories by enabling [detached environments](../reference/pixi_configuration.md#detached-environments). @@ -36,13 +36,13 @@ Pixi will always make sure the environment is in sync with the `pixi.lock` file. If this is not the case then all the commands that use the environment will automatically update the environment, e.g. `pixi run`, `pixi shell`. ### Environment Installation Metadata -On environment installation, pixi will write a small file to the environment that contains some metadata about installation. +On environment installation, Pixi will write a small file to the environment that contains some metadata about installation. This file is called `pixi` and is located in the `conda-meta` folder of the environment. This file contains the following information: - `manifest_path`: The path to the manifest file that describes the workspace used to create this environment - `environment_name`: The name of the environment -- `pixi_version`: The version of pixi that was used to create this environment +- `pixi_version`: The version of Pixi that was used to create this environment - `environment_lock_file_hash`: The hash of the `pixi.lock` file that was used to create this environment ```json @@ -55,7 +55,7 @@ This file contains the following information: ``` The `environment_lock_file_hash` is used to check if the environment is in sync with the `pixi.lock` file. -If the hash of the `pixi.lock` file is different from the hash in the `pixi` file, pixi will update the environment. +If the hash of the `pixi.lock` file is different from the hash in the `pixi` file, Pixi will update the environment. This is used to speedup activation, in order to trigger a full revalidation pass `--revalidate` to the `pixi run` or `pixi shell` command. A broken environment would typically not be found with a hash comparison, but a revalidation would reinstall the environment. @@ -63,7 +63,7 @@ By default, all lock file modifying commands will always use the revalidation an ### Cleaning up -If you want to clean up the environments, you can simply delete the `.pixi/envs` directory, and pixi will recreate the environments when needed. +If you want to clean up the environments, you can simply delete the `.pixi/envs` directory, and Pixi will recreate the environments when needed. ```shell # either: @@ -90,7 +90,7 @@ To do the activation we have multiple options: Where the `run` command is special as it runs its own cross-platform shell and has the ability to run tasks. More information about tasks can be found in the [tasks documentation](advanced_tasks.md). -Using the `pixi shell-hook` in pixi you would get the following output: +Using the `pixi shell-hook` in Pixi you would get the following output: ```shell export PATH="/home/user/development/pixi/.pixi/envs/default/bin:/home/user/.local/bin:/home/user/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/home/user/.pixi/bin" @@ -195,9 +195,9 @@ The following environment variables are set by pixi, when using the `pixi run`, ## Solving environments -When you run a command that uses the environment, pixi will check if the environment is in sync with the `pixi.lock` file. -If it is not, pixi will solve the environment and update it. -This means that pixi will retrieve the best set of packages for the dependency requirements that you specified in the `pixi.toml` and will put the output of the solve step into the `pixi.lock` file. +When you run a command that uses the environment, Pixi will check if the environment is in sync with the `pixi.lock` file. +If it is not, Pixi will solve the environment and update it. +This means that Pixi will retrieve the best set of packages for the dependency requirements that you specified in the `pixi.toml` and will put the output of the solve step into the `pixi.lock` file. Solving is a mathematical problem and can take some time, but we take pride in the way we solve environments, and we are confident that we can solve your environment in a reasonable time. If you want to learn more about the solving process, you can read these: @@ -211,12 +211,12 @@ It also supports the `conda` way of solving, which means that it downloads the m For the `[pypi-dependencies]`, `uv` implements `sdist` building to retrieve the metadata of the packages, and `wheel` building to install the packages. For this building step, `pixi` requires to first install `python` in the (conda)`[dependencies]` section of the `pixi.toml` file. -This will always be slower than the pure conda solves. So for the best pixi experience you should stay within the `[dependencies]` section of the `pixi.toml` file. +This will always be slower than the pure conda solves. So for the best Pixi experience you should stay within the `[dependencies]` section of the `pixi.toml` file. ## Caching packages Pixi caches all previously downloaded packages in a cache folder. -This cache folder is shared between all pixi projects and globally installed tools. +This cache folder is shared between all Pixi projects and globally installed tools. Normally the location would be the following platform-specific default cache folder: @@ -227,7 +227,7 @@ platform-specific default cache folder: This location is configurable by setting the `PIXI_CACHE_DIR` or `RATTLER_CACHE_DIR` environment variable. -When you want to clean the cache, you can simply delete the cache directory, and pixi will re-create the cache when needed. +When you want to clean the cache, you can simply delete the cache directory, and Pixi will re-create the cache when needed. The cache contains multiple folders concerning different caches from within pixi. diff --git a/docs/environments/lockfile.md b/docs/environments/lockfile.md index d43ee7ca40..107c6d7178 100644 --- a/docs/environments/lockfile.md +++ b/docs/environments/lockfile.md @@ -1,11 +1,11 @@ # The `pixi.lock` lock file -> A lock file is the protector of the environments, and pixi is the key to unlock it. +> A lock file is the protector of the environments, and Pixi is the key to unlock it. ## What is a lock file? A lock file locks the environment in a specific state. -Within pixi a lock file is a description of the packages in an environment. +Within Pixi a lock file is a description of the packages in an environment. The lock file contains two definitions: - The environments that are used in the workspace with their complete set of packages. e.g.: @@ -119,7 +119,7 @@ All the commands that support the interaction with the lock file also include so The lock file is a description of the environment, and it should always be satisfiable. Satisfiable means that the given manifest file and the created environment are in sync with the lockfile. -If the lock file is not satisfiable, pixi will generate a new lock file automatically. +If the lock file is not satisfiable, Pixi will generate a new lock file automatically. Steps to check if the lock file is satisfiable: diff --git a/docs/environments/multi_platform_configuration.md b/docs/environments/multi_platform_configuration.md index 0db419cf39..16307e934c 100644 --- a/docs/environments/multi_platform_configuration.md +++ b/docs/environments/multi_platform_configuration.md @@ -52,7 +52,7 @@ Here is an example manifest file that highlights some of the features: ## Platform definition The `workspace.platforms` defines which platforms your project supports. -When multiple platforms are defined, pixi determines which dependencies to install for each platform individually. +When multiple platforms are defined, Pixi determines which dependencies to install for each platform individually. All of this is stored in a lock file. Running `pixi install` on a platform that is not configured will warn the user that it is not setup for that platform: @@ -73,7 +73,7 @@ Running `pixi install` on a platform that is not configured will warn the user t ## Target specifier With the target specifier, you can overwrite the original configuration specifically for a single platform. -If you are targeting a specific platform in your target specifier that was not specified in your `project.platforms` then pixi will throw an error. +If you are targeting a specific platform in your target specifier that was not specified in your `project.platforms` then Pixi will throw an error. ### Dependencies diff --git a/docs/environments/system_requirements.md b/docs/environments/system_requirements.md index a5b81703b2..d827543955 100644 --- a/docs/environments/system_requirements.md +++ b/docs/environments/system_requirements.md @@ -1,5 +1,5 @@ # System Requirements in pixi -**System requirements** tell pixi the minimum system specifications needed to install and run your workspace’s environment. +**System requirements** tell Pixi the minimum system specifications needed to install and run your workspace’s environment. They ensure that the dependencies match the operating system and hardware of your machine. Think of it like this: @@ -7,12 +7,12 @@ You’re defining what “kind of computer” your workspace can run on. For example, you might require a specific Linux kernel version or a minimum glibc version. If your machine doesn’t meet these requirements, `pixi run` will fail because the environment can’t work reliably on your system. -When resolving dependencies, pixi combines: +When resolving dependencies, Pixi combines: - The default requirements for the operating system. - Any custom requirements you’ve added for your workspace through the `[system-requirements]`. -This way, pixi guarantees your environment is consistent and compatible with your machine. +This way, Pixi guarantees your environment is consistent and compatible with your machine. System specifications are closely related to [virtual packages](https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-virtual.html), allowing for flexible and accurate dependency management. diff --git a/docs/getting_started.md b/docs/getting_started.md index 24489ae2b0..3449e5d923 100644 --- a/docs/getting_started.md +++ b/docs/getting_started.md @@ -12,7 +12,7 @@ In this simple example we have a single task `start` which runs a Python file an However, you might wonder why we need to specify the platforms if Pixi could just extract this information from your operating system. That is because every dependency in your environment is stored in the lockfile called `pixi.lock`. This ensures that even if you run your workspace on a different platform, the environment will contain exactly the dependencies that were solved on your machine. -This is one of the core features that makes pixi reproducible. +This is one of the core features that makes Pixi reproducible. Learn more about lock files in [this chapter](./environments/lockfile.md). @@ -105,7 +105,7 @@ pixi run --environment=py312 start ## Going further -There is still much more that pixi has to offer. +There is still much more that Pixi has to offer. Check out the topics on the sidebar on the left to learn more. And don't forget to [join our Discord](https://discord.gg/kKV8ZxyzY4) to join our community of Pixi enthusiasts! diff --git a/docs/global_tools/introduction.md b/docs/global_tools/introduction.md index 900051f732..99e6b68b98 100644 --- a/docs/global_tools/introduction.md +++ b/docs/global_tools/introduction.md @@ -9,7 +9,7 @@ With `pixi global`, users can manage globally installed tools in a way that makes them available from any directory. -This means that the pixi environment will be placed in a global location, and the tools will be exposed to the system `PATH`, allowing you to run them from the command line. +This means that the Pixi environment will be placed in a global location, and the tools will be exposed to the system `PATH`, allowing you to run them from the command line. ## Basic Usage @@ -58,7 +58,7 @@ py3 -c "print('Hello World')" ## The Global Manifest -Since `v0.33.0` pixi has a new manifest file that will be created in the global directory. +Since `v0.33.0` Pixi has a new manifest file that will be created in the global directory. This file will contain the list of environments that are installed globally, their dependencies and exposed binaries. The manifest can be edited, synced, checked in to a version control system, and shared with others. diff --git a/docs/index.md b/docs/index.md index f729f78407..2f555a0086 100644 --- a/docs/index.md +++ b/docs/index.md @@ -8,15 +8,12 @@ Pixi is a package management tool for developers. - 🔄 **Reproducibility**: Work in dedicated, isolated environments that can be easily recreated. - 🛠️ **Tasks**: Manage complex pipelines effortlessly. - 🌐 **Multi Platform**: Ensure compatibility across Linux, macOS, Windows, and more. -- 🧩 **Multi Environment**: Compose multiple environments within a single pixi manifest. +- 🧩 **Multi Environment**: Compose multiple environments within a single Pixi manifest. - 🏗️ **Building**: Build packages from source using powerful build backends. - 📦 **Distributing**: Distribute your software via conda channels or various other options. - 🐍 **Python**: Full support for `pyproject.toml` and PyPI dependencies. - 🌍 **Global Tools**: Install globally available tools, safely stored in separate environments. -It allows the developer to install libraries and applications in a reproducible way. -Use pixi cross-platform, on Windows, Mac and Linux. - ## Installation To install `pixi` you can run the following command in your terminal: @@ -54,7 +51,7 @@ pixi init hello-world cd hello-world ``` -This will create a pixi manifest which is a file called `pixi.toml`. +This will create a Pixi manifest which is a file called `pixi.toml`. It describes the structure, dependencies and metadata of your workspace. ```toml title="pixi.toml" @@ -79,7 +76,7 @@ We can now create a Python script which uses the `cowpy` library. --8<-- "docs/source_files/pixi_workspaces/introduction/deps_add/hello.py" ``` -The dependencies are installed in a pixi environment. +The dependencies are installed in a Pixi environment. In order to run a command within an environment, we prefix it with `pixi run`. ```bash diff --git a/docs/integration/editor/jupyterlab.md b/docs/integration/editor/jupyterlab.md index 3519a2944b..6703c733a9 100644 --- a/docs/integration/editor/jupyterlab.md +++ b/docs/integration/editor/jupyterlab.md @@ -1,8 +1,8 @@ ## Basic usage -Using JupyterLab with pixi is very simple. -You can just create a new pixi workspace and add the `jupyterlab` package to it. +Using JupyterLab with Pixi is very simple. +You can just create a new Pixi workspace and add the `jupyterlab` package to it. The full example is provided under the following [Github link](https://github.com/prefix-dev/pixi/tree/main/examples/jupyterlab). ```bash @@ -10,7 +10,7 @@ pixi init pixi add jupyterlab ``` -This will create a new pixi workspace and add the `jupyterlab` package to it. You can then start JupyterLab using the +This will create a new Pixi workspace and add the `jupyterlab` package to it. You can then start JupyterLab using the following command: ```bash diff --git a/docs/integration/editor/pycharm.md b/docs/integration/editor/pycharm.md index 2d1fa6847b..900eb4d96a 100644 --- a/docs/integration/editor/pycharm.md +++ b/docs/integration/editor/pycharm.md @@ -1,10 +1,10 @@ -You can use PyCharm with pixi environments by using the `conda` shim provided by the [pixi-pycharm](https://github.com/pavelzw/pixi-pycharm) package. +You can use PyCharm with Pixi environments by using the `conda` shim provided by the [pixi-pycharm](https://github.com/pavelzw/pixi-pycharm) package. ## How to use -To get started, add `pixi-pycharm` to your pixi workspace. +To get started, add `pixi-pycharm` to your Pixi workspace. ```bash pixi add pixi-pycharm @@ -12,7 +12,7 @@ pixi add pixi-pycharm This will ensure that the conda shim is installed in your workspace's environment. -Having `pixi-pycharm` installed, you can now configure PyCharm to use your pixi environments. +Having `pixi-pycharm` installed, you can now configure PyCharm to use your Pixi environments. Go to the _Add Python Interpreter_ dialog (bottom right corner of the PyCharm window) and select _Conda Environment_. Set _Conda Executable_ to the full path of the `conda` file (on Windows: `conda.bat`) which is located in `.pixi/envs/default/libexec`. You can get the path using the following command: @@ -30,14 +30,14 @@ You can get the path using the following command: This is an executable that tricks PyCharm into thinking it's the proper `conda` executable. Under the hood it redirects all calls to the corresponding `pixi` equivalent. -!!!warning "Use the conda shim from this pixi workspace" - Please make sure that this is the `conda` shim from this pixi workspace and not another one. - If you use multiple pixi projects, you might have to adjust the path accordingly as PyCharm remembers the path to the conda executable. +!!!warning "Use the conda shim from this Pixi workspace" + Please make sure that this is the `conda` shim from this Pixi workspace and not another one. + If you use multiple Pixi projects, you might have to adjust the path accordingly as PyCharm remembers the path to the conda executable. ![Add Python Interpreter](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/add-conda-environment-light.png#only-light) ![Add Python Interpreter](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/add-conda-environment-dark.png#only-dark) -Having selected the environment, PyCharm will now use the Python interpreter from your pixi environment. +Having selected the environment, PyCharm will now use the Python interpreter from your Pixi environment. PyCharm should now be able to show you the installed packages as well. @@ -67,17 +67,17 @@ You can now run your programs and tests as usual. If your workspace uses [multiple environments](../../environments/multi_environment.md) to tests different Python versions or dependencies, you can add multiple environments to PyCharm by specifying _Use existing environment_ in the _Add Python Interpreter_ dialog. -![Multiple pixi environments](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/python-interpreters-multi-env-light.png#only-light) -![Multiple pixi environments](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/python-interpreters-multi-env-dark.png#only-dark) +![Multiple Pixi environments](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/python-interpreters-multi-env-light.png#only-light) +![Multiple Pixi environments](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/python-interpreters-multi-env-dark.png#only-dark) You can then specify the corresponding environment in the bottom right corner of the PyCharm window. ![Specify environment](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/specify-interpreter-light.png#only-light) ![Specify environment](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/specify-interpreter-dark.png#only-dark) -### Multiple pixi projects +### Multiple Pixi projects -When using multiple pixi projects, remember to select the correct _Conda Executable_ for each workspace as mentioned above. +When using multiple Pixi projects, remember to select the correct _Conda Executable_ for each workspace as mentioned above. It also might come up that you have multiple environments with the same name. ![Multiple default environments](https://raw.githubusercontent.com/pavelzw/pixi-pycharm/main/.github/assets/multiple-default-envs-light.png#only-light) diff --git a/docs/integration/third_party/starship.md b/docs/integration/third_party/starship.md index e6084cfeda..702903bfa8 100644 --- a/docs/integration/third_party/starship.md +++ b/docs/integration/third_party/starship.md @@ -1,11 +1,11 @@ # Starship -![Starship with pixi support](../../assets/starship-light.png#only-light) -![Starship with pixi support](../../assets/starship-dark.png#only-dark) +![Starship with Pixi support](../../assets/starship-light.png#only-light) +![Starship with Pixi support](../../assets/starship-dark.png#only-dark) [Starship](https://starship.rs) is a cross-platform and cross-shell prompt for developers, similar to oh-my-zsh, but with a focus on performance and simplicity. -In [starship/starship #6335](https://github.com/starship/starship/pull/6335), pixi support is being added. +In [starship/starship #6335](https://github.com/starship/starship/pull/6335), Pixi support is being added. This pull request has not been merged at the time of writing. That's why [@pavelzw](https://github.com/pavelzw) created a conda package for his fork in [prefix.dev/yolo-forge](https://prefix.dev/channels/yolo-forge). The packages are being built in GitHub Actions in the [pavelzw/yolo-forge GitHub repository](https://github.com/pavelzw/yolo-forge) using `rattler-build`. diff --git a/docs/packaging.md b/docs/packaging.md index 2aa797d258..4a8a7daa32 100644 --- a/docs/packaging.md +++ b/docs/packaging.md @@ -1,14 +1,14 @@ # Packaging Pixi -This is a guide for distribution maintainers wanting to package pixi for a different package manager. -Users of pixi can ignore this page. +This is a guide for distribution maintainers wanting to package Pixi for a different package manager. +Users of Pixi can ignore this page. ## Building Pixi is written in Rust and compiled using Cargo, which are needed as compile-time dependencies. -At runtime pixi needs no dependencies in other than the runtime it was compiled against (`libc`, ...). +At runtime Pixi needs no dependencies in other than the runtime it was compiled against (`libc`, ...). -To build pixi run +To build Pixi run ```shell cargo build --locked --profile dist ``` @@ -21,13 +21,13 @@ Pixi provides some compile-time options, which can influence the build #### TLS -By default, pixi is built with Rustls TLS implementation. You can compile pixi using the platform native TLS implementation +By default, Pixi is built with Rustls TLS implementation. You can compile Pixi using the platform native TLS implementation using by adding `--no-default-features --feature native-tls` to the build command. Note that this might add additional runtime dependencies, such as OpenSSL on Linux. #### Self-Update -Pixi has a self-update functionality. When pixi is installed using another package manager one usually doesn't want pixi +Pixi has a self-update functionality. When Pixi is installed using another package manager one usually doesn't want pixi to try to update itself and instead let it be updated by the package manager. For this reason the self-update feature is disabled by default. It can be enabled by adding `--feature self_update` to the build command. @@ -49,7 +49,7 @@ PIXI_VERSION="HEAD-123456" cargo build --locked --profile dist ## Shell completion -After building pixi you can generate shell autocompletion scripts by running +After building Pixi you can generate shell autocompletion scripts by running ```shell pixi completion --shell ``` diff --git a/docs/python/pyproject_toml.md b/docs/python/pyproject_toml.md index db895627eb..bd0478cfba 100644 --- a/docs/python/pyproject_toml.md +++ b/docs/python/pyproject_toml.md @@ -13,7 +13,7 @@ When you already have a `pyproject.toml` file in your project, you can run `pixi - Add the current project as an editable pypi dependency; - Add some defaults to the `.gitignore` and `.gitattributes` files. -If you do not have an existing `pyproject.toml` file , you can run `pixi init --format pyproject` in your project folder. In that case, pixi will create a `pyproject.toml` manifest from scratch with some sane defaults. +If you do not have an existing `pyproject.toml` file , you can run `pixi init --format pyproject` in your project folder. In that case, Pixi will create a `pyproject.toml` manifest from scratch with some sane defaults. ## Python dependency @@ -106,13 +106,13 @@ matplotlib = "*" ``` This would result in the conda dependencies being installed and the pypi dependencies being ignored. -As pixi takes the conda dependencies over the pypi dependencies. +As Pixi takes the conda dependencies over the pypi dependencies. ## Optional dependencies -If your python project includes groups of optional dependencies, pixi will automatically interpret them as [pixi features](../reference/pixi_manifest.md#the-feature-table) of the same name with the associated `pypi-dependencies`. +If your python project includes groups of optional dependencies, Pixi will automatically interpret them as [Pixi features](../reference/pixi_manifest.md#the-feature-table) of the same name with the associated `pypi-dependencies`. -You can add them to pixi environments manually, or use `pixi init` to setup the project, which will create one environment per feature. Self-references to other groups of optional dependencies are also handled. +You can add them to Pixi environments manually, or use `pixi init` to setup the project, which will create one environment per feature. Self-references to other groups of optional dependencies are also handled. For instance, imagine you have a project folder with a `pyproject.toml` file similar to: @@ -157,9 +157,9 @@ All environments will be solved together, as indicated by the common `solve-grou ## Dependency groups -If your python project includes dependency groups, pixi will automatically interpret them as [pixi features](../reference/pixi_manifest.md#the-feature-table) of the same name with the associated `pypi-dependencies`. +If your python project includes dependency groups, Pixi will automatically interpret them as [Pixi features](../reference/pixi_manifest.md#the-feature-table) of the same name with the associated `pypi-dependencies`. -You can add them to pixi environments manually, or use `pixi init` to setup the project, which will create one environment per dependency group. +You can add them to Pixi environments manually, or use `pixi init` to setup the project, which will create one environment per dependency group. For instance, imagine you have a project folder with a `pyproject.toml` file similar to: @@ -208,7 +208,7 @@ All environments will be solved together, as indicated by the common `solve-grou ## Example -As the `pyproject.toml` file supports the full pixi spec with `[tool.pixi]` prepended an example would look like this: +As the `pyproject.toml` file supports the full Pixi spec with `[tool.pixi]` prepended an example would look like this: ```toml title="pyproject.toml" [project] @@ -250,7 +250,7 @@ test = ["test"] The `pyproject.toml` file normally contains a `[build-system]` section. Pixi will use this section to build and install the project if it is added as a pypi path dependency. -If the `pyproject.toml` file does not contain any `[build-system]` section, pixi will fall back to [uv](https://github.com/astral-sh/uv)'s default, which is equivalent to the below: +If the `pyproject.toml` file does not contain any `[build-system]` section, Pixi will fall back to [uv](https://github.com/astral-sh/uv)'s default, which is equivalent to the below: ```toml title="pyproject.toml" [build-system] diff --git a/docs/python/pytorch.md b/docs/python/pytorch.md index cd3d238a51..7d58bda097 100644 --- a/docs/python/pytorch.md +++ b/docs/python/pytorch.md @@ -10,19 +10,19 @@ This guide explains how to integrate PyTorch with `pixi`, it supports multiple w With these options you can choose the best way to install PyTorch based on your requirements. ## System requirements -In the context of PyTorch, [**system requirements**](../environments/system_requirements.md) help pixi understand whether it can install and use CUDA-related packages. +In the context of PyTorch, [**system requirements**](../environments/system_requirements.md) help Pixi understand whether it can install and use CUDA-related packages. These requirements ensure compatibility during dependency resolution. The key mechanism here is the use of virtual packages like __cuda. Virtual packages signal the available system capabilities (e.g., CUDA version). -By specifying `system-requirements.cuda = "12"`, you are telling pixi that CUDA version 12 is available and can be used during resolution. +By specifying `system-requirements.cuda = "12"`, you are telling Pixi that CUDA version 12 is available and can be used during resolution. For example: -- If a package depends on `__cuda >= 12`, pixi will resolve the correct version. +- If a package depends on `__cuda >= 12`, Pixi will resolve the correct version. - If a package depends on `__cuda` without version constraints, any available CUDA version can be used. -Without setting the appropriate `system-requirements.cuda`, pixi will default to installing the **CPU-only** versions of PyTorch and its dependencies. +Without setting the appropriate `system-requirements.cuda`, Pixi will default to installing the **CPU-only** versions of PyTorch and its dependencies. A more in-depth explanation of system requirements can be found [here](../environments/system_requirements.md). @@ -112,7 +112,7 @@ Best to do this per dependency to force the index to be used. --8<-- "docs/source_files/pyproject_tomls/pytorch-pypi.toml:minimal" ``` -You can tell pixi to use multiple environment for the multiple versions of PyTorch, either `cpu` or `gpu`. +You can tell Pixi to use multiple environment for the multiple versions of PyTorch, either `cpu` or `gpu`. === "`pixi.toml`" ```toml title="Use multiple environments for the pypi pytorch installation" @@ -130,14 +130,14 @@ pixi run -e gpu python -c "import torch; print(torch.__version__); print(torch.c ``` ### Mixing MacOS and CUDA with `pypi-dependencies` -When using pypi-dependencies, pixi creates a “solve” environment to resolve the PyPI dependencies. +When using pypi-dependencies, Pixi creates a “solve” environment to resolve the PyPI dependencies. This process involves installing the Conda dependencies first and then resolving the PyPI packages within that environment. This can become problematic if you’re on a macOS machine and trying to resolve the CUDA version of PyTorch for Linux or Windows. Since macOS doesn’t support those environments, the Conda dependencies for CUDA will fail to install, preventing proper resolution. **Current Status:** -The pixi maintainers are aware of this limitation and are actively working on a solution to enable cross-platform dependency resolution for such cases. +The Pixi maintainers are aware of this limitation and are actively working on a solution to enable cross-platform dependency resolution for such cases. In the meantime, you may need to run the resolution process on a machine that supports CUDA, such as a Linux or Windows host. @@ -167,7 +167,7 @@ pixi run python -c "import torch; print(torch.__version__); print(torch.cuda.is_ ``` #### Checking the CUDA version of your machine -To check which CUDA version pixi detects on your machine, run: +To check which CUDA version Pixi detects on your machine, run: ``` pixi info ``` @@ -212,7 +212,7 @@ To summarize: #### GPU version of `pytorch` not installing: 1. Using [conda-Forge](#installing-from-conda-forge) - - Ensure `system-requirements.cuda` is set to inform pixi to install CUDA-enabled packages. + - Ensure `system-requirements.cuda` is set to inform Pixi to install CUDA-enabled packages. - Use the `cuda-version` package to pin the desired CUDA version. 2. Using [PyPI](#installing-from-pypi) - Use the appropriate PyPI index to fetch the correct CUDA-enabled wheels. diff --git a/docs/python/tutorial.md b/docs/python/tutorial.md index 0bcc59b2e4..9bd90d1611 100644 --- a/docs/python/tutorial.md +++ b/docs/python/tutorial.md @@ -1,7 +1,7 @@ # Tutorial: Doing Python development with Pixi In this tutorial, we will show you how to create a simple Python project with pixi. -We will show some of the features that pixi provides, that are currently not a part of `pdm`, `poetry` etc. +We will show some of the features that Pixi provides, that are currently not a part of `pdm`, `poetry` etc. ## Why is this useful? @@ -57,7 +57,7 @@ pixi_py = { path = ".", editable = true } [tool.pixi.tasks] ``` -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). +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). ### What's in the `pyproject.toml`? @@ -206,14 +206,14 @@ werkzeug 3.1.3 743 KiB pypi werkzeug-3.1. ``` Here, you can see the different conda and Pypi packages listed. As you can see, the `pixi-py` package that we are working on is installed in editable mode. -Every environment in pixi is isolated but reuses files that are hard-linked from a central cache directory. +Every environment in Pixi is isolated but reuses files that are hard-linked from a central cache directory. This means that you can have multiple environments with the same packages but only have the individual files stored once on disk. ??? question "Why does the environment have a Python interpreter?" The Python interpreter is also installed in the environment. This is because the Python interpreter version is read from the `requires-python` field in the `pyproject.toml` file. This is used to determine the Python version to install in the environment. - This way, pixi automatically manages/bootstraps the Python interpreter for you, so no more `brew`, `apt` or other system install steps. + This way, Pixi automatically manages/bootstraps the Python interpreter for you, so no more `brew`, `apt` or other system install steps. ??? question "How to use the Free-threaded interpreter?" If you want to use a free-threaded Python interpreter, you can add the `python-freethreading` dependency to the `[tool.pixi.dependencies]`. @@ -223,7 +223,7 @@ This means that you can have multiple environments with the same packages but on Pixi can also create multiple environments, this works well together with the `dependency-groups` feature in the `pyproject.toml` file. -Let's add a dependency-group, which pixi calls a `feature`, named `test`. +Let's add a dependency-group, which Pixi calls a `feature`, named `test`. And add the `pytest` package to this group. ```shell @@ -237,7 +237,7 @@ This results in the package being added to the `dependency-groups` following the test = ["pytest"] ``` -After we have added the `dependency-groups` to the `pyproject.toml`, pixi sees these as a [`feature`](../reference/pixi_manifest.md/#the-feature-and-environments-tables), which can contain a collection of `dependencies`, `tasks`, `channels`, and more. +After we have added the `dependency-groups` to the `pyproject.toml`, Pixi sees these as a [`feature`](../reference/pixi_manifest.md/#the-feature-and-environments-tables), which can contain a collection of `dependencies`, `tasks`, `channels`, and more. ```shell @@ -259,7 +259,7 @@ test = { features = ["test"], solve-group = "default" } For example, maybe `pytest` is a dependency that influences the dependencies of the `default` environment. By putting these in the same solve group, you ensure that the versions in `test` and `default` are exactly the same. -Without specifying the environment name, pixi will default to the `default` environment. +Without specifying the environment name, Pixi will default to the `default` environment. If you want to install or run the `test` environment, you can specify the environment with the `--environment` flag. ```shell @@ -300,7 +300,7 @@ Hello, World! 🧛 ``` ??? note "Slow?" - This might be slow the first time because pixi installs the project, but it will be near instant the second time. + This might be slow the first time because Pixi installs the project, but it will be near instant the second time. Pixi runs the self installed Python interpreter. Then, we are importing the `pixi_py` package, which is installed in editable mode. @@ -337,11 +337,11 @@ Let's add an easy task for running the tests. pixi task add --feature test test "pytest" ``` -So pixi has a task system to make it easy to run commands. +So Pixi has a task system to make it easy to run commands. Similar to `npm` scripts or something you would specify in a `Justfile`. !!! tip "Pixi tasks" - Tasks are a cool pixi feature that is powerful and runs in a cross-platform shell. + Tasks are a cool Pixi feature that is powerful and runs in a cross-platform shell. You can do caching, dependencies and more. Read more about tasks in the [tasks](../environments/advanced_tasks.md) section. @@ -364,7 +364,7 @@ test_me.py . ??? question "Why didn't I have to specify the environment?" The `test` task was added to the `test` feature/environment. - When you run the `test` task, pixi automatically switches to the `test` environment. + When you run the `test` task, Pixi automatically switches to the `test` environment. Because that is the only environment that has the task. Neat! It seems to be working! @@ -396,7 +396,7 @@ There is a [docker](https://github.com/prefix-dev/pixi/tree/main/examples/docker ## Replacing PyPI packages with conda packages -Last thing, pixi provides the ability for `pypi` packages to depend on `conda` packages. +Last thing, Pixi provides the ability for `pypi` packages to depend on `conda` packages. Let's confirm this with: ```shell pixi list pygments @@ -447,7 +447,7 @@ And it still works! ## Conclusion -In this tutorial, you've seen how easy it is to use a `pyproject.toml` to manage your pixi dependencies and environments. +In this tutorial, you've seen how easy it is to use a `pyproject.toml` to manage your Pixi dependencies and environments. We have also explored how to use PyPI and conda dependencies seamlessly together in the same project and install optional dependencies to manage Python packages. Hopefully, this provides a flexible and powerful way to manage your Python projects and a fertile base for further exploration with Pixi. diff --git a/docs/reference/pixi_configuration.md b/docs/reference/pixi_configuration.md index 7edd3fda63..189f560921 100644 --- a/docs/reference/pixi_configuration.md +++ b/docs/reference/pixi_configuration.md @@ -1,6 +1,6 @@ -# The configuration of pixi itself +# The configuration of Pixi itself -Apart from the [project specific configuration](../reference/pixi_manifest.md) pixi supports configuration options which are not required for the project to work but are local to the machine. +Apart from the [project specific configuration](../reference/pixi_manifest.md) Pixi supports configuration options which are not required for the project to work but are local to the machine. The configuration is loaded in the following order: @@ -49,7 +49,7 @@ The configuration is loaded in the following order: ## Configuration options ??? info "Casing In Configuration" - In versions of pixi `0.20.1` and older the global configuration used `snake_case` which + In versions of Pixi `0.20.1` and older the global configuration used `snake_case` which we've changed to `kebab-case` for consistency with the rest of the configuration. But we still support the old `snake_case` configuration, for older configuration options. These are: @@ -80,7 +80,7 @@ This defaults to only conda-forge. You can override this from the CLI with `--change-ps1`. - `force-activate`: When set to `true` the re-activation of the environment will always happen. This is used in combination with the [`experimental`](#experimental) feature `use-environment-activation-cache`. -- `source-completion-scripts`: When set to `false`, pixi will not source the autocompletion scripts of the environment when going into the shell. +- `source-completion-scripts`: When set to `false`, Pixi will not source the autocompletion scripts of the environment when going into the shell. ```toml title="config.toml" --8<-- "docs/source_files/pixi_config_tomls/main_config.toml:shell" @@ -109,7 +109,7 @@ Read more in the authentication section. ``` ### `detached-environments` -The directory where pixi stores the project environments, what would normally be placed in the `.pixi/envs` folder in a project's root. +The directory where Pixi stores the project environments, what would normally be placed in the `.pixi/envs` folder in a project's root. It doesn't affect the environments built for `pixi global`. The location of environments created for a `pixi global` installation can be controlled using the `PIXI_HOME` environment variable. !!! warning @@ -200,7 +200,7 @@ To setup a certain number of defaults for the usage of PyPI registries. You can ### `s3-options` -Configuration for S3 authentication. This will lead to pixi not using AWS's default credentials but instead use the credentials from the pixi authentication storage, see the [S3 section](../deployment/s3.md) for more information. +Configuration for S3 authentication. This will lead to Pixi not using AWS's default credentials but instead use the credentials from the Pixi authentication storage, see the [S3 section](../deployment/s3.md) for more information. ```toml title="config.toml" --8<-- "docs/source_files/pixi_config_tomls/main_config.toml:s3-options" diff --git a/docs/reference/pixi_manifest.md b/docs/reference/pixi_manifest.md index 93ca882889..ef1caaab64 100644 --- a/docs/reference/pixi_manifest.md +++ b/docs/reference/pixi_manifest.md @@ -1,9 +1,9 @@ -The `pixi.toml` is the project manifest, also known as the pixi project configuration file. +The `pixi.toml` is the project manifest, also known as the Pixi project configuration file. A `toml` file is structured in different tables. This document will explain the usage of the different tables. -For more technical documentation check pixi on [docs.rs](https://docs.rs/pixi/latest/pixi/project/manifest/struct.ProjectManifest.html). +For more technical documentation check Pixi on [docs.rs](https://docs.rs/pixi/latest/pixi/project/manifest/struct.ProjectManifest.html). !!! tip We also support the `pyproject.toml` file. It has the same structure as the `pixi.toml` file. except that you need to prepend the tables with `tool.pixi` instead of just the table name. @@ -215,9 +215,9 @@ channel-priority = "disabled" Tasks are a way to automate certain custom commands in your project. For example, a `lint` or `format` step. -Tasks in a pixi project are essentially cross-platform shell commands, with a unified syntax across platforms. +Tasks in a Pixi project are essentially cross-platform shell commands, with a unified syntax across platforms. For more in-depth information, check the [Advanced tasks documentation](../environments/advanced_tasks.md). -Pixi's tasks are run in a pixi environment using `pixi run` and are executed using the [`deno_task_shell`](../environments/advanced_tasks.md#our-task-runner-deno_task_shell). +Pixi's tasks are run in a Pixi environment using `pixi run` and are executed using the [`deno_task_shell`](../environments/advanced_tasks.md#our-task-runner-deno_task_shell). ```toml [tasks] @@ -305,7 +305,7 @@ extra-index-urls = ["https://example.com/simple"] find-links = [{path = './links'}] ``` -There are some [examples](https://github.com/prefix-dev/pixi/tree/main/examples/pypi-custom-registry) in the pixi repository, that make use of this feature. +There are some [examples](https://github.com/prefix-dev/pixi/tree/main/examples/pypi-custom-registry) in the Pixi repository, that make use of this feature. !!! tip "Authentication Methods" To read about existing authentication methods for private registries, please check the [PyPI Authentication](../deployment/authentication.md#pypi-authentication) section. @@ -512,7 +512,7 @@ pytest = { git = "https://github.com/pytest-dev/pytest.git"} #### Full specification -The full specification of a PyPI dependencies that pixi supports can be split into the following fields: +The full specification of a PyPI dependencies that Pixi supports can be split into the following fields: ##### `extras` @@ -528,7 +528,7 @@ minimal-project = { path = "./minimal-project", editable = true, extras = ["dev" ##### `version` -The version of the package to install. e.g. `">=1.0.0"` or `*` which stands for any version, this is pixi specific. +The version of the package to install. e.g. `">=1.0.0"` or `*` which stands for any version, this is Pixi specific. Version is our default field so using no inline table (`{}`) will default to this field. ```toml @@ -665,7 +665,7 @@ The platform can be any of: The sub-table can be any of the specified above. To make it a bit more clear, let's look at an example below. -Currently, pixi combines the top level tables like `dependencies` with the target-specific ones into a single set. +Currently, Pixi combines the top level tables like `dependencies` with the target-specific ones into a single set. Which, in the case of dependencies, can both add or overwrite dependencies. In the example below, we have `cmake` being used for all targets but on `osx-64` or `osx-arm64` a different version of python will be selected. diff --git a/docs/switching_from/conda.md b/docs/switching_from/conda.md index 75ed5f0dfe..d59aab22c9 100644 --- a/docs/switching_from/conda.md +++ b/docs/switching_from/conda.md @@ -25,7 +25,7 @@ This shift towards projects offers a more organized and efficient way to manage **Pixi does not have a base environment**. And requires you to install the tools you need in the workspace or globally. Using `pixi global install bat` will install `bat` in a global environment, which is not the same as the `base` environment in conda. -??? tip "Activating pixi environment in the current shell" +??? tip "Activating Pixi environment in the current shell" For some advanced use-cases, you can activate the environment in the current shell. This uses the `pixi shell-hook` which prints the activation script, which can be used to activate the environment in the current shell without `pixi` itself. ```shell @@ -64,7 +64,7 @@ bat pixi.toml ## Automated switching -With `pixi` you can import `environment.yml` files into a pixi workspace. (See [import](../reference/cli.md#init)) +With `pixi` you can import `environment.yml` files into a Pixi workspace. (See [import](../reference/cli.md#init)) ```shell pixi init --import environment.yml ``` diff --git a/docs/switching_from/poetry.md b/docs/switching_from/poetry.md index 8c7fd405f1..fb76034ef4 100644 --- a/docs/switching_from/poetry.md +++ b/docs/switching_from/poetry.md @@ -4,7 +4,7 @@ This document compares key commands and concepts between these tools, highlighti With `pixi`, you'll experience a workspace-based workflow similar to `poetry` while including the `conda` ecosystem and allowing for easy sharing of your work. ## Why Pixi? -Poetry is most-likely the closest tool to pixi in terms of workspace management, in the python ecosystem. +Poetry is most-likely the closest tool to Pixi in terms of workspace management, in the python ecosystem. On top of the PyPI ecosystem, `pixi` adds the power of the conda ecosystem, allowing for a more flexible and powerful environment management. ## Quick look at the differences @@ -32,5 +32,5 @@ Make sure that `python` is only defined in the `tool.pixi.dependencies` and not Pixi supports PyPI dependencies in a different way than `poetry` does, and mixing them can lead to unexpected behavior. As you can only use one package manager at a time, it's best to stick to one. - If using poetry on top of a pixi workspace, you'll always need to install the `poetry` environment after the `pixi` environment. + If using poetry on top of a Pixi workspace, you'll always need to install the `poetry` environment after the `pixi` environment. And let `pixi` handle the `python` and `poetry` installation. diff --git a/docs/tutorials/multi_environment.md b/docs/tutorials/multi_environment.md index 7a7a4624bb..7322597593 100644 --- a/docs/tutorials/multi_environment.md +++ b/docs/tutorials/multi_environment.md @@ -1,13 +1,13 @@ # Tutorial: Using multiple environments -In this tutorial we will show you how to use multiple environments in one pixi workspace. +In this tutorial we will show you how to use multiple environments in one Pixi workspace. ## Why is this useful? When developing a workspace you often need different tools, libraries or test environments. -With pixi you can define multiple environments in one workspace and switch between them easily. +With Pixi you can define multiple environments in one workspace and switch between them easily. A developer often needs all the tools they can get, whereas your testing infrastructure might not require all those tools, and your production environment might require even less. -Setting up different environments for these different use cases can be a hassle, but with pixi it's easy. +Setting up different environments for these different use cases can be a hassle, but with Pixi it's easy. ## Glossary This tutorial possibly uses some new terms, here is a quick overview: @@ -28,7 +28,7 @@ These top level table, are added to the "default" feature, which is added to eve ## Let's get started -We'll simply start with a new workspace, you can skip this step if you already have a pixi workspace. +We'll simply start with a new workspace, you can skip this step if you already have a Pixi workspace. ```shell pixi init workspace @@ -36,7 +36,7 @@ cd workspace pixi add python ``` -Now we have a new pixi workspace with the following structure: +Now we have a new Pixi workspace with the following structure: ``` ├── .pixi │   └── envs @@ -46,7 +46,7 @@ Now we have a new pixi workspace with the following structure: ``` Note the `.pixi/envs/default` directory, this is where the default environment is stored. -If no environment is specified, pixi will create or use the `default` environment. +If no environment is specified, Pixi will create or use the `default` environment. ### Adding a feature diff --git a/docs/tutorials/ros2.md b/docs/tutorials/ros2.md index 2acbd07c0e..fd6aabf3ff 100644 --- a/docs/tutorials/ros2.md +++ b/docs/tutorials/ros2.md @@ -3,7 +3,7 @@ In this tutorial, we will show you how to develop a ROS 2 package using `pixi`. The tutorial is written to be executed from top to bottom, missing steps might result in errors. -The audience for this tutorial is developers who are familiar with ROS 2 and how are interested to try pixi for their development workflow. +The audience for this tutorial is developers who are familiar with ROS 2 and how are interested to try Pixi for their development workflow. ## Prerequisites @@ -12,7 +12,7 @@ The audience for this tutorial is developers who are familiar with ROS 2 and how - On Windows, it's advised to enable Developer mode. Go to Settings -> Update & Security -> For developers -> Developer mode. -## Create a pixi workspace +## Create a Pixi workspace ```shell pixi init my_ros2_project -c robostack-staging -c conda-forge @@ -46,12 +46,12 @@ platforms = ["linux-64"] ``` The `channels` you added to the `init` command are repositories of packages, you can search in these repositories through our [prefix.dev](https://prefix.dev/channels) website. -The `platforms` are the systems you want to support, in pixi you can support multiple platforms, but you have to define which platforms, so pixi can test if those are supported for your dependencies. +The `platforms` are the systems you want to support, in Pixi you can support multiple platforms, but you have to define which platforms, so Pixi can test if those are supported for your dependencies. For the rest of the fields, you can fill them in as you see fit. ## Add ROS 2 dependencies -To use a pixi project you don't need any dependencies on your system, all the dependencies you need should be added through pixi, so other users can use your project without any issues. +To use a Pixi project you don't need any dependencies on your system, all the dependencies you need should be added through pixi, so other users can use your project without any issues. Let's start with the `turtlesim` example @@ -110,7 +110,7 @@ pixi run colcon build ``` This will create a sourceable script in the `install` folder, you can source this script through an activation script to use your custom node. -Normally this would be the script you add to your `.bashrc` but instead you tell pixi to use it by adding the following to `pixi.toml`: +Normally this would be the script you add to your `.bashrc` but instead you tell Pixi to use it by adding the following to `pixi.toml`: === "Linux & macOS" ```toml title="pixi.toml" @@ -222,8 +222,8 @@ Let's inspire the community together! ### What happens with `rosdep`? -Currently, we don't support `rosdep` in a pixi environment, so you'll have to add the packages using `pixi add`. -`rosdep` will call `conda install` which isn't supported in a pixi environment. +Currently, we don't support `rosdep` in a Pixi environment, so you'll have to add the packages using `pixi add`. +`rosdep` will call `conda install` which isn't supported in a Pixi environment. ### Community examples diff --git a/docs/tutorials/rust.md b/docs/tutorials/rust.md index 19581d5dde..82abe02991 100644 --- a/docs/tutorials/rust.md +++ b/docs/tutorials/rust.md @@ -3,7 +3,7 @@ In this tutorial, we will show you how to develop a Rust package using `pixi`. The tutorial is written to be executed from top to bottom, missing steps might result in errors. -The audience for this tutorial is developers who are familiar with Rust and `cargo` and how are interested to try pixi for their development workflow. +The audience for this tutorial is developers who are familiar with Rust and `cargo` and how are interested to try Pixi for their development workflow. The benefit would be within a rust workflow that you lock both rust and the C/System dependencies your project might be using. For example tokio users might depend on `openssl` for linux. @@ -12,7 +12,7 @@ The benefit would be within a rust workflow that you lock both rust and the C/Sy - You need to have `pixi` installed. If you haven't installed it yet, you can follow the instructions in the [installation guide](../index.md). The crux of this tutorial is to show you only need pixi! -## Create a pixi project. +## Create a Pixi project. ```shell pixi init my_rust_project @@ -48,7 +48,7 @@ platforms = ["linux-64"] # (1)! ## Add Rust dependencies -To use a pixi project you don't need any dependencies on your system, all the dependencies you need should be added through pixi, so other users can use your project without any issues. +To use a Pixi project you don't need any dependencies on your system, all the dependencies you need should be added through pixi, so other users can use your project without any issues. ```shell pixi add rust ``` diff --git a/docs/vision.md b/docs/vision.md index e9823f0b91..43582618f1 100644 --- a/docs/vision.md +++ b/docs/vision.md @@ -6,13 +6,13 @@ Modern package managers like `cargo` have shown us, how great a package manager ## Pixi values -We want to make pixi a great experience for everyone, so we have a few values that we want to uphold: +We want to make Pixi a great experience for everyone, so we have a few values that we want to uphold: 1. **Fast**. We want to have a fast package manager, that is able to solve the environment in a few seconds. 2. **User Friendly**. We want to have a package manager that puts user friendliness on the front-line. Providing easy, accessible and intuitive commands. That have the element of _least surprise_. 3. **Isolated Environment**. We want to have isolated environments, that are reproducible and easy to share. Ideally, it should run on all common platforms. The Conda packaging system provides an excellent base for this. 4. **Single Tool**. We want to integrate most common uses when working on a development workspace with Pixi, so it should support at least dependency management, command management, building and uploading packages. You should not need to reach to another external tool for this. -5. **Fun**. It should be fun to use pixi and not cause frustrations, you should not need to think about it a lot and it should generally just get out of your way. +5. **Fun**. It should be fun to use Pixi and not cause frustrations, you should not need to think about it a lot and it should generally just get out of your way. ## Conda