docs: rename more instances of project to workspace

docs/advanced/channel_logic.md

@@ -32,7 +32,7 @@ flowchart TD
 ```
 
 # Channel priority
-Channel priority is dictated by the order in the `project.channels` array, where the first channel is the highest priority.
+Channel priority is dictated by the order in the `workspace.channels` array, where the first channel is the highest priority.
 For instance:
 ```toml
 [workspace]
@@ -95,7 +95,7 @@ If you want to force a specific priority for a channel, you can use the `priorit
 The higher the number, the higher the priority.
 Non specified priorities are set to 0 but the index in the array still counts as a priority, where the first in the list has the highest priority.
 
-This priority definition is mostly important for [multiple environments](../environments/multi_environment.md) with different channel priorities, as by default feature channels are prepended to the project channels.
+This priority definition is mostly important for [multiple environments](../environments/multi_environment.md) with different channel priorities, as by default feature channels are prepended to the workspace channels.
 
 ```toml
 [workspace]

docs/advanced/explain_info_command.md

@@ -1,5 +1,5 @@
 
-`pixi info` prints out useful information to debug a situation or to get an overview of your machine/project.
+`pixi info` prints out useful information to debug a situation or to get an overview of your machine/workspace.
 This information can also be retrieved in `json` format using the `--json` flag, which can be useful for programmatically reading it.
 
 ```title="Running pixi info in the pixi repo"
@@ -14,7 +14,7 @@ This information can also be retrieved in `json` format using the `--json` flag,
          Cache dir: /home/user/.cache/rattler/cache
       Auth storage: /home/user/.rattler/credentials.json
 
-Project
+Workspace
 ------------
            Version: 0.13.0
      Manifest file: /home/user/development/pixi/pixi.toml
@@ -64,14 +64,14 @@ Check the [authentication documentation](../deployment/authentication.md)
 
 The size of the previously mentioned "Cache dir" in Mebibytes.
 
-## Project info
+## Workspace info
 
-Everything below `Project` is info about the project you're currently in.
+Everything below `Workspace` is info about the workspace you're currently in.
 This info is only available if your path has a [manifest file](../reference/pixi_manifest.md).
 
 ### Manifest file
 
-The path to the [manifest file](../reference/pixi_manifest.md) that describes the project.
+The path to the [manifest file](../reference/pixi_manifest.md) that describes the workspace.
 
 ### Last updated
 
@@ -100,4 +100,4 @@ The list of dependencies defined for this environment.
 
 ### Target platforms
 
-The platforms the project has defined.
+The platforms the workspace has defined.

docs/build/backends.md

@@ -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 projects.
+5. This will allow pixi to install desired backends from the `pixi-build-backends` channel, and any requirements from `conda-forge`. Backends are installed into isolated environments, and will be shared across pixi workspaces.
 
 ### Overriding the Build Backend
 Sometimes you want to override the build backend that is used by pixi. Meaning overriding the backend that is specified in the [`[package.build]`](../reference/pixi_manifest.md#the-build-system). We currently have two environment variables that allow for this:

docs/build/cpp.md

@@ -1,19 +1,19 @@
 # Tutorial: Building a C++ package
 
-This example shows how to build a C++ project with CMake and use it together with `pixi-build`.
+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.
 
-We'll start off by creating a project that use [nanobind](https://github.com/wjakob/nanobind) to build Python bindings.
+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.
 We'll later combine this example together with a Python package.
 
 !!! warning
     `pixi-build` is a preview feature, and will change until it is stabilized.
-    Please keep that in mind when you use it for your projects.
+    Please keep that in mind when you use it for your workspaces.
 
-## Creating a new project
+## Creating a new workspace
 
-To get started, create a new project with pixi:
+To get started, create a new workspace with pixi:
 
 ```bash
 pixi init python_bindings
@@ -31,7 +31,7 @@ python_bindings/
     └── bindings.cpp
 ```
 
-## Creating the project files
+## Creating the workspace files
 Next up we'll create the:
 
 - `pixi.toml` file that will be used to configure pixi.
@@ -54,7 +54,7 @@ Use the following `pixi.toml` file, you can hover over the annotations to see wh
 6. We use the [nanobind](https://github.com/wjakob/nanobind) package to build our bindings.
 7. We need python to build the bindings, so we add a host dependency on the `python` package.
 8. We override the cmake version to ensure it matches our `CMakeLists.txt` file.
-9. Optionally, we can add extra arguments to the CMake invocation (e.g. `-DCMAKE_BUILD_TYPE=Release` or `-DUSE_FOOBAR=True`). This totally depends on the specific project / CMakeLists.txt file.
+9. Optionally, we can add extra arguments to the CMake invocation (e.g. `-DCMAKE_BUILD_TYPE=Release` or `-DUSE_FOOBAR=True`). This totally depends on the specific workspace / CMakeLists.txt file.
 
 ### The `CMakeLists.txt` file
 

docs/build/dependency_types.md

@@ -18,15 +18,15 @@ Let's delve deeper into the various types of package dependencies and their spec
     When using the `pixi-build-cmake` backend you do not need to specify `cmake` or the compiler as a dependency.
     The backend will install `cmake`, `ninja` and the C++ compilers by default.
 
-This table contains dependencies that are needed to build the project.
+This table contains dependencies that are needed to build the workspace.
 Different from dependencies and host-dependencies these packages are installed for the architecture of the build machine.
 This enables cross-compiling from one machine architecture to another.
 
 Typical examples of build dependencies are:
 
 - Compilers are invoked on the build machine, but they generate code for the target machine.
-  If the project is cross-compiled, the architecture of the build and target machine might differ.
-- `cmake` is invoked on the build machine to generate additional code- or project-files which are then include in the compilation process.
+  If the package is cross-compiled, the architecture of the build and target machine might differ.
+- `cmake` is invoked on the build machine to generate additional files which are then include in the compilation process.
 
 !!! info
     The _build_ target refers to the machine that will execute the build.
@@ -43,7 +43,7 @@ In contrast, the libraries you link to are host dependencies since they are spec
 Typical examples of host dependencies are:
 
 - Base interpreters: a Python package would list `python` here and an R package would list `mro-base` or `r-base`.
-- Libraries your project links against like `openssl`, `rapidjson`, or `xtensor`.
+- Libraries your package links against like `openssl`, `rapidjson`, or `xtensor`.
 
 #### Python code
 Because of the way building currently works, dependencies like `hatchling`,`pip`,`uv` etc. are host dependencies.

docs/build/getting_started.md

@@ -29,7 +29,7 @@ This is an overview of the pixi manifest using `pixi-build`.
 ```
 
 
-Under the `[workspace]` section, you can specify properties like the name, channels, and platforms. This is currently an alias for `project`.
+Under the `[workspace]` section, you can specify properties like the name, channels, and platforms. This is currently an alias for `[project]`.
 
 Since the build feature is still in preview, you have to add "pixi-build" to `workspace.preview`.
 

docs/deployment/container.md

@@ -1,6 +1,6 @@
 # Bringing pixi to production
 
-You can bring pixi projects into production by either containerizing 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.
 
 <!-- Keep in sync with https://github.com/prefix-dev/pixi-docker/blob/main/README.md -->
 

docs/deployment/pixi_pack.md

@@ -67,7 +67,7 @@ You can inject additional packages into the environment that are not specified i
 pixi-pack pack --inject local-package-1.0.0-hbefa133_0.conda --manifest-pack pixi.toml
 ```
 
-This can be particularly useful if you build the project itself and want to include the built package in the environment but still want to use `pixi.lock` from the project.
+This can be particularly useful if you build the package itself and want to include the built package in the environment but still want to use `pixi.lock` from the workspace.
 
 ### Cache downloaded packages
 

docs/deployment/s3.md

@@ -86,18 +86,18 @@ jobs:
 
 ## Using pixi's configuration
 
-You can specify the `project.s3-options` in your `pixi.toml` file.
+You can specify the `workspace.s3-options` in your `pixi.toml` file.
 This might be useful when you want to use a custom S3-compatible host and not AWS's configuration.
 
 ```toml title="pixi.toml"
-[project.s3-options.my-bucket]
+[workspace.s3-options.my-bucket]
 endpoint-url = "https://my-s3-host"
 region = "us-east-1"
 force-path-style = false
 ```
 
 !!!note ""
-    You need to configure this per bucket you use, i.e. use `[project.s3-options.<bucket-name>]`.
+    You need to configure this per bucket you use, i.e. use `[workspace.s3-options.<bucket-name>]`.
 
 ```bash
 $ pixi auth login --aws-access-key-id=... --aws-secret-access-key=... s3://my-s3-bucket
@@ -187,7 +187,7 @@ You can use them with pixi by specifying the `s3-options` in your manifest file.
 ### MinIO
 
 ```toml title="pixi.toml"
-[project.s3-options]
+[workspace.s3-options]
 endpoint-url = "https://minio.example.com"
 region = "us-east-1"
 force-path-style = true

docs/environments/advanced_tasks.md

@@ -1,6 +1,6 @@
 
 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 project.
+Steps like formatting, linting, compiling, testing, benchmarking, etc. are often part of a workspace.
 With pixi tasks, this should become much easier to do.
 
 Here are some quick examples
@@ -106,7 +106,7 @@ 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.
 
-Consider a pixi project structured as follows:
+Consider a pixi workspace structured as follows:
 
 ```shell
 ├── pixi.toml

docs/environments/environment.md

@@ -6,9 +6,9 @@ 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 project by default.
-This keeps your machine and your project clean and isolated from each other, and makes it easy to clean up after a project is done.
-While this structure is generally recommended, environments can also be stored outside of project directories by enabling [detached environments](../reference/pixi_configuration.md#detached-environments).
+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).
 
 If you look at the `.pixi/envs` directory, you will see a directory for each environment, the `default` being the one that is normally used, if you specify a custom environment the name you specified will be used.
 
@@ -40,7 +40,7 @@ On environment installation, pixi will write a small file to the environment tha
 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 project used to create this environment
+- `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
 - `environment_lock_file_hash`: The hash of the `pixi.lock` file that was used to create this environment

docs/environments/lockfile.md

@@ -8,7 +8,7 @@ A lock file locks the environment in a specific state.
 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 project with their complete set of packages. e.g.:
+- The environments that are used in the workspace with their complete set of packages. e.g.:
 
   ```yaml
   environments:
@@ -61,7 +61,7 @@ The lock file contains two definitions:
 Pixi uses the lock file for the following reasons:
 
 - To save a working installation state, without copying the entire environment's data.
-- To ensure the project configuration is aligned with the installed environment.
+- To ensure the workspace configuration is aligned with the installed environment.
 - To give the user a file that contains all the information about the environment.
 
 This gives you (and your collaborators) a way to really reproduce the environment they are working in.
@@ -161,7 +161,7 @@ But take note of the following:
 
 - A lock file allows you to run the same environment on different machines, think CI systems.
 - It also allows you to go back to a working state if you have made a mistake.
-- It helps other users onboard to your project as they don't have to figure out the environment setup or solve dependency issues.
+- It helps other users onboard to your workspace as they don't have to figure out the environment setup or solve dependency issues.
 
 ## Removing the lock file
 

docs/environments/multi_environment.md

@@ -8,10 +8,10 @@ There are multiple scenarios where multiple environments are useful.
 - **Smaller single tool environments**, e.g. `lint` or `docs`.
 - **Large developer environments**, that combine all the smaller environments, e.g. `dev`.
 - **Strict supersets of environments**, e.g. `prod` and `test-prod` where `test-prod` is a strict superset of `prod`.
-- **Multiple machines from one project**, e.g. a `cuda` environment and a `cpu` environment.
+- **Multiple system requirements within one workspace**, e.g. a `cuda` environment and a `cpu` environment.
 - **And many more.** (Feel free to edit this document in our GitHub and add your use case.)
 
-This prepares `pixi` for use in large projects with multiple use-cases, multiple developers and different CI needs.
+This prepares `pixi` for use in large workspaces with multiple use-cases, multiple developers and different CI needs.
 
 ## Design Considerations
 
@@ -346,7 +346,7 @@ Initial write-up of the proposal: [GitHub Gist by 0xbe7a](https://gist.github.co
 
 ??? tip "Test vs Production example"
 
-    This is an example of a project that has a `test` feature and `prod` environment.
+    This is an example of a workspace that has a `test` feature and `prod` environment.
     The `prod` environment is a production environment that contains the run dependencies.
     The `test` feature is a set of dependencies and tasks that we want to put on top of the previously solved `prod` environment.
     This is a common use case where we want to test the production environment with additional dependencies.
@@ -404,16 +404,16 @@ Initial write-up of the proposal: [GitHub Gist by 0xbe7a](https://gist.github.co
     CMD ["/usr/local/bin/pixi", "run", "--environment", "prod", "serve"]
     ```
 
-??? tip "Multiple machines from one project"
-    This is an example for an ML project that should be executable on a machine that supports `cuda` and `mlx`. It should also be executable on machines that don't support `cuda` or `mlx`, we use the `cpu` feature for this.
+??? tip "Multiple machines from one workspace"
+    This is an example for an ML workspace that should be executable on a machine that supports `cuda` and `mlx`. It should also be executable on machines that don't support `cuda` or `mlx`, we use the `cpu` feature for this.
 
     ```toml title="pixi.toml"
     [workspace]
-    name = "my-ml-project"
-    description = "A project that does ML stuff"
+    name = "my-ml-workspace"
+    description = "A workspace that does ML stuff"
     authors = ["Your Name <your.name@gmail.com>"]
     channels = ["conda-forge", "pytorch"]
-    # All platforms that are supported by the project as the features will take the intersection of the platforms defined there.
+    # All platforms that are supported by the workspace as the features will take the intersection of the platforms defined there.
     platforms = ["win-64", "linux-64", "osx-64", "osx-arm64"]
 
     [tasks]
@@ -461,18 +461,18 @@ Initial write-up of the proposal: [GitHub Gist by 0xbe7a](https://gist.github.co
     default = ["cpu"]
     ```
 
-    ```shell title="Running the project on a cuda machine"
+    ```shell title="Executing on a cuda machine"
     pixi run train-model --environment cuda
     # will execute `python train.py --cuda`
     # fails if not on linux-64 or win-64 with cuda 12.1
     ```
 
-    ```shell title="Running the project with mlx"
+    ```shell title="Executing with mlx"
     pixi run train-model --environment mlx
     # will execute `python train.py --mlx`
     # fails if not on osx-arm64
     ```
 
-    ```shell title="Running the project on a machine without cuda or mlx"
+    ```shell title="Executing on a machine without cuda or mlx"
     pixi run train-model
     ```

docs/environments/multi_platform_configuration.md

@@ -7,7 +7,7 @@ Here is an example manifest file that highlights some of the features:
 === "`pixi.toml`"
     ```toml title="pixi.toml"
     [workspace]
-    # Default project info....
+    # Default workspace info....
     # A list of platforms you are supporting with your package.
     platforms = ["win-64", "linux-64", "osx-64", "osx-arm64"]
 
@@ -29,7 +29,7 @@ Here is an example manifest file that highlights some of the features:
 === "`pyproject.toml`"
     ```toml title="pyproject.toml"
     [tool.pixi.workspace]
-    # Default project info....
+    # Default workspace info....
     # A list of platforms you are supporting with your package.
     platforms = ["win-64", "linux-64", "osx-64", "osx-arm64"]
 
@@ -51,7 +51,7 @@ Here is an example manifest file that highlights some of the features:
 
 ## Platform definition
 
-The `project.platforms` defines which platforms your project supports.
+The `workspace.platforms` defines which platforms your project supports.
 When multiple platforms are defined, pixi determines which dependencies to install for each platform individually.
 All of this is stored in a lock file.