docs: Switchable toml code snippets

crates/pixi_build_r/Cargo.toml

@@ -1,9 +1,9 @@
 [package]
+description = "R build backend for Pixi"
 edition.workspace = true
 license.workspace = true
 name = "pixi_build_r"
 version = "0.1.0"
-description = "R build backend for Pixi"
 
 [[bin]]
 name = "pixi-build-r"

docs/advanced/channel_logic.md

@@ -7,13 +7,23 @@ Therefore, this document will continue with simplified flow charts.
 ## Channel Specific Dependencies
 
 When a user defines a channel per dependency, the solver needs to know the other channels are unusable for this dependency.
-```toml
-[workspace]
-channels = ["conda-forge", "my-channel"]
+=== "pixi.toml"
+    ```toml
+    [workspace]
+    channels = ["conda-forge", "my-channel"]
 
-[dependencies]
-packgex = { version = "*", channel = "my-channel" }
-```
+    [dependencies]
+    packgex = { version = "*", channel = "my-channel" }
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.workspace]
+    channels = ["conda-forge", "my-channel"]
+
+    [tool.pixi.dependencies]
+    packgex = { version = "*", channel = "my-channel" }
+    ```
 In the `packagex` example, the solver will understand that the package is only available in `my-channel` and will not look for it in `conda-forge`.
 
 The flowchart of the logic that excludes all other channels:
@@ -33,10 +43,17 @@ flowchart TD
 
 Channel priority is dictated by the order in the `workspace.channels` array, where the first channel is the highest priority.
 For instance:
-```toml
-[workspace]
-channels = ["conda-forge", "my-channel", "your-channel"]
-```
+=== "pixi.toml"
+    ```toml
+    [workspace]
+    channels = ["conda-forge", "my-channel", "your-channel"]
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.workspace]
+    channels = ["conda-forge", "my-channel", "your-channel"]
+    ```
 If the package is found in `conda-forge` the solver will not look for it in `my-channel` and `your-channel`, because it tells the solver they are excluded.
 If the package is not found in `conda-forge` the solver will look for it in `my-channel` and if it **is** found there it will tell the solver to exclude `your-channel` for this package.
 This diagram explains the logic:
@@ -63,18 +80,33 @@ If you have 10 channels and the package is found in the 5th channel it will excl
 
 ## Use Case: pytorch and nvidia with conda-forge
 A common use case is to use `pytorch` with `nvidia` drivers, while also needing the `conda-forge` channel for the main dependencies.
-```toml
-[workspace]
-channels = ["nvidia/label/cuda-11.8.0", "nvidia", "conda-forge", "pytorch"]
-platforms = ["linux-64"]
-
-[dependencies]
-cuda = {version = "*", channel="nvidia/label/cuda-11.8.0"}
-pytorch = {version = "2.0.1.*", channel="pytorch"}
-torchvision = {version = "0.15.2.*", channel="pytorch"}
-pytorch-cuda = {version = "11.8.*", channel="pytorch"}
-python = "3.10.*"
-```
+=== "pixi.toml"
+    ```toml
+    [workspace]
+    channels = ["nvidia/label/cuda-11.8.0", "nvidia", "conda-forge", "pytorch"]
+    platforms = ["linux-64"]
+
+    [dependencies]
+    cuda = {version = "*", channel="nvidia/label/cuda-11.8.0"}
+    pytorch = {version = "2.0.1.*", channel="pytorch"}
+    torchvision = {version = "0.15.2.*", channel="pytorch"}
+    pytorch-cuda = {version = "11.8.*", channel="pytorch"}
+    python = "3.10.*"
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.workspace]
+    channels = ["nvidia/label/cuda-11.8.0", "nvidia", "conda-forge", "pytorch"]
+    platforms = ["linux-64"]
+
+    [tool.pixi.dependencies]
+    cuda = {version = "*", channel="nvidia/label/cuda-11.8.0"}
+    pytorch = {version = "2.0.1.*", channel="pytorch"}
+    torchvision = {version = "0.15.2.*", channel="pytorch"}
+    pytorch-cuda = {version = "11.8.*", channel="pytorch"}
+    python = "3.10.*"
+    ```
 What this will do is get as much as possible from the `nvidia/label/cuda-11.8.0` channel, which is actually only the `cuda` package.
 
 Then it will get all packages from the `nvidia` channel, which is a little more and some packages overlap the `nvidia` and `conda-forge` channel.
@@ -96,26 +128,49 @@ Non specified priorities are set to 0 but the index in the array still counts as
 
 This priority definition is mostly important for [multiple environments](../workspace/multi_environment.md) with different channel priorities, as by default feature channels are prepended to the workspace channels.
 
-```toml
-[workspace]
-name = "test_channel_priority"
-platforms = ["linux-64", "osx-64", "win-64", "osx-arm64"]
-channels = ["conda-forge"]
+=== "pixi.toml"
+    ```toml
+    [workspace]
+    name = "test_channel_priority"
+    platforms = ["linux-64", "osx-64", "win-64", "osx-arm64"]
+    channels = ["conda-forge"]
 
-[feature.a]
-channels = ["nvidia"]
+    [feature.a]
+    channels = ["nvidia"]
 
-[feature.b]
-channels = [ "pytorch", {channel = "nvidia", priority = 1}]
+    [feature.b]
+    channels = [ "pytorch", {channel = "nvidia", priority = 1}]
 
-[feature.c]
-channels = [ "pytorch", {channel = "nvidia", priority = -1}]
+    [feature.c]
+    channels = [ "pytorch", {channel = "nvidia", priority = -1}]
 
-[environments]
-a = ["a"]
-b = ["b"]
-c = ["c"]
-```
+    [environments]
+    a = ["a"]
+    b = ["b"]
+    c = ["c"]
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.workspace]
+    name = "test_channel_priority"
+    platforms = ["linux-64", "osx-64", "win-64", "osx-arm64"]
+    channels = ["conda-forge"]
+
+    [tool.pixi.feature.a]
+    channels = ["nvidia"]
+
+    [tool.pixi.feature.b]
+    channels = [ "pytorch", {channel = "nvidia", priority = 1}]
+
+    [tool.pixi.feature.c]
+    channels = [ "pytorch", {channel = "nvidia", priority = -1}]
+
+    [tool.pixi.environments]
+    a = ["a"]
+    b = ["b"]
+    c = ["c"]
+    ```
 This example creates 4 environments, `a`, `b`, `c`, and the default environment.
 Which will have the following channel order:
 

docs/advanced/override.md

@@ -7,27 +7,33 @@ Sometimes our direct dependency declares outdated intermediate dependency or is
 
 ## Example
 ### Override a dependency version
-```toml
-# pyproject.toml
-[tool.pixi.pypi-options.dependency-overrides]
-numpy = ">=2.0.0"
-```
-or in `pixi.toml`:
-
-```toml
-# pixi.toml
-[pypi-options.dependency-overrides]
-numpy = ">=2.0.0"
-```
+=== "pixi.toml"
+    ```toml
+    [pypi-options.dependency-overrides]
+    numpy = ">=2.0.0"
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.pypi-options.dependency-overrides]
+    numpy = ">=2.0.0"
+    ```
 This will override the version of `numpy` used by all dependencies to be at least `2.0.0`, regardless of what the dependencies specify.
 This is useful if you need a specific version of a library that is not compatible with the versions specified by your dependencies.
 
 ### Override a dependency version in a specific feature
 it can also be specified in feature level,
-```toml
-[features.dev.pypi-options.dependency-overrides]
-numpy = ">=2.0.0"
-```
+=== "pixi.toml"
+    ```toml
+    [feature.dev.pypi-options.dependency-overrides]
+    numpy = ">=2.0.0"
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.feature.dev.pypi-options.dependency-overrides]
+    numpy = ">=2.0.0"
+    ```
 This will override the version of `numpy` used by all dependencies in the `dev` feature to be at least `2.0.0`, regardless of what the dependencies specify when the `dev` feature is enabled.
 
 ### Interact with other overrides
@@ -38,26 +44,47 @@ If the same dependency is overridden multiple times, we'll use the override from
 
 Also, the default feature will always come, and come last in the list of all overrides.
 
-```toml
-# pixi.toml
-[pypi-options]
-dependency-overrides = { numpy = ">=2.1.0" }
+=== "pixi.toml"
+    ```toml
+    [pypi-options]
+    dependency-overrides = { numpy = ">=2.1.0" }
+
+    [pypi-dependencies]
+    numpy = ">=1.25.0"
+
+    [feature.dev.pypi-options.dependency-overrides]
+    numpy = "==2.0.0"
+
+    [feature.outdated.pypi-options.dependency-overrides]
+    numpy = "==1.21.0"
+
+    [environments]
+    dev = ["dev"]
+    outdated = ["outdated"]
+    conflict_a=["outdated", "dev"]
+    conflict_b=["dev","outdated"]
+    ```
+
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.pypi-options]
+    dependency-overrides = { numpy = ">=2.1.0" }
 
-[pypi-dependencies]
-numpy = ">=1.25.0"
+    [tool.pixi.pypi-dependencies]
+    numpy = ">=1.25.0"
 
-[feature.dev.pypi-options.dependency-overrides]
-numpy = "==2.0.0"
+    [tool.pixi.feature.dev.pypi-options.dependency-overrides]
+    numpy = "==2.0.0"
 
-[feature.outdated.pypi-options.dependency-overrides]
-numpy = "==1.21.0"
+    [tool.pixi.feature.outdated.pypi-options.dependency-overrides]
+    numpy = "==1.21.0"
 
-[environments]
-dev = ["dev"]
-outdated = ["outdated"]
-conflict_a=["outdated", "dev"]
-conflict_b=["dev","outdated"]
-```
+    [tool.pixi.environments]
+    dev = ["dev"]
+    outdated = ["outdated"]
+    conflict_a=["outdated", "dev"]
+    conflict_b=["dev","outdated"]
+    ```
 the following constrains are merged out:
 default: `numpy >= 2.1.0`
 dev: `numpy == 2.0.0`

docs/build/advanced_cpp.md

@@ -27,9 +27,14 @@ To get started, please recreate the structure of the workspace from the previous
 
 We are now using the `pixi-build-rattler-build` backend instead of the `pixi-build-cmake` backend.
 
-```toml hl_lines="20-21"
---8<-- "docs/source_files/pixi_workspaces/pixi_build/advanced_cpp/pixi.toml"
-```
+=== "pixi.toml"
+    ```toml hl_lines="20-21"
+    --8<-- "docs/source_files/pixi_workspaces/pixi_build/advanced_cpp/pixi.toml"
+    ```
+=== "pyproject.toml"
+    ```toml hl_lines="20-21"
+    --8<-- "docs/source_files/pyproejct_tomls_advanced_cpp/pixi.toml"
+    ```
 
 ## The `recipe.yaml` file
 
@@ -50,10 +55,16 @@ You can find the reference on the `rattler-build` documentation [web page](https
 
 Now that we've defined a `pixi` task which allows us to check that our package can properly add `1` and `2`:
 
-```toml
-[tasks]
-start = "python -c 'import cpp_math as b; print(b.add(1, 2))'"
-```
+=== "pixi.toml"
+    ```toml
+    [tasks]
+    start = "python -c 'import cpp_math as b; print(b.add(1, 2))'"
+    ```
+=== "pyproject.toml"
+    ```toml
+    [tool.pixi.tasks]
+    start = "python -c 'import cpp_math as b; print(b.add(1, 2))'"
+    ```
 
 Executing the tasks works as expected
 

docs/build/backends/pixi-build-python.md

@@ -5,11 +5,16 @@ The `pixi-build-python` backend is designed for building Python projects using s
 !!! warning
     `pixi-build` is a preview feature, and will change until it is stabilized.
     This is why we require users to opt in to that feature by adding "pixi-build" to `workspace.preview`.
-
-    ```toml
-    [workspace]
-    preview = ["pixi-build"]
-    ```
+    === "pixi.toml"
+        ```toml
+        [workspace]
+        preview = ["pixi-build"]
+        ```
+    === "pyproject.toml"
+        ```toml
+        [tool.pixi.workspace]
+        preview = ["pixi-build"]
+        ```
 
 
 ## Overview

docs/build/backends/pixi-build-rattler-build.md

@@ -78,10 +78,19 @@ model only provides the workspace structure information that the recipe cannot k
 
 To specify source dependencies, add them to `build-dependencies`, `host-dependencies` or `run-dependencies` in the package manifest:
 
-```toml title="pixi.toml"
-[package.build-dependencies]
-a = { path = "../a" }
-```
+=== "pixi.toml"
+
+    ```toml
+    [package.build-dependencies]
+    a = { path = "../a" }
+    ```
+
+=== "pyproject.toml"
+
+    ```toml
+    [tool.pixi.package.build-dependencies]
+    a = { path = "../a" }
+    ```
 
 ## Configuration Options
 
@@ -165,3 +174,4 @@ The rattler-build backend follows this build process:
 - Requires an existing rattler-build recipe file - cannot infer build instructions automatically
 - Build configuration is primarily controlled through the recipe file rather than `pixi.toml`
 - Cannot specify binary dependencies in the manifest
+