From 4bd1b908e8bb44c3681ec40a6f5533d753da9eb0 Mon Sep 17 00:00:00 2001 From: Julian Hofer Date: Fri, 7 Mar 2025 14:11:58 +0100 Subject: [PATCH] docs: rename more instances of project to workspace --- docs/advanced/channel_logic.md | 4 ++-- docs/advanced/explain_info_command.md | 12 +++++----- docs/build/backends.md | 2 +- docs/build/cpp.md | 14 +++++------ docs/build/dependency_types.md | 8 +++---- docs/build/getting_started.md | 2 +- docs/deployment/container.md | 2 +- docs/deployment/pixi_pack.md | 2 +- docs/deployment/s3.md | 8 +++---- docs/environments/advanced_tasks.md | 4 ++-- docs/environments/environment.md | 8 +++---- docs/environments/lockfile.md | 6 ++--- docs/environments/multi_environment.md | 22 ++++++++--------- .../multi_platform_configuration.md | 6 ++--- docs/environments/system_requirements.md | 20 ++++++++-------- docs/index.md | 2 +- docs/integration/ci/github_actions.md | 2 +- docs/integration/editor/devcontainer.md | 8 +++---- docs/integration/editor/jupyterlab.md | 8 +++---- docs/integration/editor/pycharm.md | 12 +++++----- docs/switching_from/conda.md | 24 +++++++++---------- docs/switching_from/poetry.md | 10 ++++---- docs/tutorials/multi_environment.md | 24 +++++++++---------- docs/tutorials/ros2.md | 2 +- docs/vision.md | 2 +- src/cli/info.rs | 2 +- 26 files changed, 108 insertions(+), 108 deletions(-) diff --git a/docs/advanced/channel_logic.md b/docs/advanced/channel_logic.md index e876edf695..9b35ec5fdd 100644 --- a/docs/advanced/channel_logic.md +++ b/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] diff --git a/docs/advanced/explain_info_command.md b/docs/advanced/explain_info_command.md index 7a88396fba..169011d9b2 100644 --- a/docs/advanced/explain_info_command.md +++ b/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. diff --git a/docs/build/backends.md b/docs/build/backends.md index c560c7a64f..9d4508deea 100644 --- a/docs/build/backends.md +++ b/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: diff --git a/docs/build/cpp.md b/docs/build/cpp.md index 4441610aff..03d58ca0a0 100644 --- a/docs/build/cpp.md +++ b/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 diff --git a/docs/build/dependency_types.md b/docs/build/dependency_types.md index 11ba521edb..2f6fa1aa0d 100644 --- a/docs/build/dependency_types.md +++ b/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. diff --git a/docs/build/getting_started.md b/docs/build/getting_started.md index 0900437bcc..880752ef5c 100644 --- a/docs/build/getting_started.md +++ b/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`. diff --git a/docs/deployment/container.md b/docs/deployment/container.md index 87aafcbcd9..3a048fc8e3 100644 --- a/docs/deployment/container.md +++ b/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. diff --git a/docs/deployment/pixi_pack.md b/docs/deployment/pixi_pack.md index aaacf2388b..b109e8a93c 100644 --- a/docs/deployment/pixi_pack.md +++ b/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 diff --git a/docs/deployment/s3.md b/docs/deployment/s3.md index b5a1637359..c46dc2b096 100644 --- a/docs/deployment/s3.md +++ b/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.]`. + You need to configure this per bucket you use, i.e. use `[workspace.s3-options.]`. ```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 diff --git a/docs/environments/advanced_tasks.md b/docs/environments/advanced_tasks.md index 078b95b8a4..d2d9469569 100644 --- a/docs/environments/advanced_tasks.md +++ b/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 diff --git a/docs/environments/environment.md b/docs/environments/environment.md index ff07cc5ba5..2267d48c04 100644 --- a/docs/environments/environment.md +++ b/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 diff --git a/docs/environments/lockfile.md b/docs/environments/lockfile.md index 1bde9f96cb..d43ee7ca40 100644 --- a/docs/environments/lockfile.md +++ b/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 diff --git a/docs/environments/multi_environment.md b/docs/environments/multi_environment.md index 4ce98f177f..662f20285c 100644 --- a/docs/environments/multi_environment.md +++ b/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 "] 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 ``` diff --git a/docs/environments/multi_platform_configuration.md b/docs/environments/multi_platform_configuration.md index 035a236f20..0db419cf39 100644 --- a/docs/environments/multi_platform_configuration.md +++ b/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. diff --git a/docs/environments/system_requirements.md b/docs/environments/system_requirements.md index a8dde3b27b..a5b81703b2 100644 --- a/docs/environments/system_requirements.md +++ b/docs/environments/system_requirements.md @@ -1,16 +1,16 @@ # System Requirements in pixi -**System requirements** tell pixi the minimum system specifications needed to install and run your project’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: -You’re defining what “kind of computer” your project can run on. +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: - The default requirements for the operating system. -- Any custom requirements you’ve added for your project through the `[system-requirements]`. +- 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. @@ -28,7 +28,7 @@ The following configurations outline the default minimal system requirements for libc = { family = "glibc", version = "2.28" } ``` === "Windows" - Windows currently has no minimal system requirements defined. If your project requires specific Windows configurations, + Windows currently has no minimal system requirements defined. If your workspace requires specific Windows configurations, you should define them accordingly. === "osx-64" ```toml @@ -45,18 +45,18 @@ The following configurations outline the default minimal system requirements for ## Customizing System Requirements -You only need to define system requirements if your project necessitates a different set from the defaults. +You only need to define system requirements if your workspace necessitates a different set from the defaults. This is common when installing environments on older or newer versions of operating systems. ### Adjusting for Older Systems If you're encountering an error like: ```bash -× The current system has a mismatching virtual package. The project requires '__linux' to be at least version '4.18' but the system has version '4.12.14' +× The current system has a mismatching virtual package. The workspace requires '__linux' to be at least version '4.18' but the system has version '4.12.14' ``` -This indicates that the project's system requirements are higher than your current system's specifications. -To resolve this, you can lower the system requirements in your project's configuration: +This indicates that the workspace's system requirements are higher than your current system's specifications. +To resolve this, you can lower the system requirements in your workspace's configuration: ```toml [system-requirements] @@ -67,7 +67,7 @@ This adjustment informs the dependency resolver to accommodate the older system ### Using CUDA in pixi -To utilize CUDA in your project, you must specify the desired CUDA version in the system-requirements table. +To utilize CUDA in your workspace, you must specify the desired CUDA version in the system-requirements table. This ensures that CUDA is recognized and appropriately locked into the lock file if necessary. Example Configuration @@ -95,7 +95,7 @@ cuda = ["cuda"] ### Available Override Options In certain scenarios, you might need to override the system requirements detected on your machine. -This can be particularly useful when working on systems that do not meet the project's default requirements. +This can be particularly useful when working on systems that do not meet the workspace's default requirements. You can override virtual packages by setting the following environment variables: diff --git a/docs/index.md b/docs/index.md index dd0a8c5083..f729f78407 100644 --- a/docs/index.md +++ b/docs/index.md @@ -47,7 +47,7 @@ Check out our [installation docs](./advanced/installation.md) to learn about alt ## Getting Started -Initialize a new project and navigate to the project directory. +Initialize a new workspace and navigate to the workspace directory. ```bash pixi init hello-world diff --git a/docs/integration/ci/github_actions.md b/docs/integration/ci/github_actions.md index 9ce0723367..c839eef9b7 100644 --- a/docs/integration/ci/github_actions.md +++ b/docs/integration/ci/github_actions.md @@ -384,7 +384,7 @@ This can be overwritten by setting the `manifest-path` input argument. ### Only install pixi -If you only want to install pixi and not install the current project, you can use the `run-install` option. +If you only want to install pixi and not install the current workspace, you can use the `run-install` option. ```yml - uses: prefix-dev/setup-pixi@v0.8.3 diff --git a/docs/integration/editor/devcontainer.md b/docs/integration/editor/devcontainer.md index ca13df055c..c1c5375e95 100644 --- a/docs/integration/editor/devcontainer.md +++ b/docs/integration/editor/devcontainer.md @@ -1,11 +1,11 @@ # Use pixi inside of a devcontainer -[VSCode Devcontainers](https://code.visualstudio.com/docs/devcontainers/containers) are a popular tool to develop on a project with a consistent environment. -They are also used in [GitHub Codespaces](https://github.com/environments/codespaces) which makes it a great way to develop on a project without having to install anything on your local machine. +[VSCode Devcontainers](https://code.visualstudio.com/docs/devcontainers/containers) are a popular tool to develop on a workspace with a consistent environment. +They are also used in [GitHub Codespaces](https://github.com/environments/codespaces) which makes it a great way to develop on a workspace without having to install anything on your local machine. To use pixi inside of a devcontainer, follow these steps: -Create a new directory `.devcontainer` in the root of your project. +Create a new directory `.devcontainer` in the root of your workspace. Then, create the following two files in the `.devcontainer` directory: ```dockerfile title=".devcontainer/Dockerfile" @@ -26,7 +26,7 @@ RUN echo 'eval "$(pixi completion -s bash)"' >> /home/vscode/.bashrc ```json title=".devcontainer/devcontainer.json" { - "name": "my-project", + "name": "my-workspace", "build": { "dockerfile": "Dockerfile", "context": "..", diff --git a/docs/integration/editor/jupyterlab.md b/docs/integration/editor/jupyterlab.md index a35f326824..3519a2944b 100644 --- a/docs/integration/editor/jupyterlab.md +++ b/docs/integration/editor/jupyterlab.md @@ -2,7 +2,7 @@ ## Basic usage Using JupyterLab with pixi is very simple. -You can just create a new pixi project and add the `jupyterlab` package to it. +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,14 +10,14 @@ pixi init pixi add jupyterlab ``` -This will create a new pixi project 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 pixi run jupyter lab ``` -If you want to add more "kernels" to JupyterLab, you can simply add them to your current project – as well as any dependencies from the scientific stack you might need. +If you want to add more "kernels" to JupyterLab, you can simply add them to your current workspace – as well as any dependencies from the scientific stack you might need. ```bash pixi add bash_kernel ipywidgets matplotlib numpy pandas # ... @@ -47,7 +47,7 @@ package. ### Configuring JupyterLab -To get started, create a Pixi project, add `jupyterlab` and `pixi-kernel` and then start JupyterLab: +To get started, create a Pixi workspace, add `jupyterlab` and `pixi-kernel` and then start JupyterLab: ```bash pixi init diff --git a/docs/integration/editor/pycharm.md b/docs/integration/editor/pycharm.md index e87f0156fd..2d1fa6847b 100644 --- a/docs/integration/editor/pycharm.md +++ b/docs/integration/editor/pycharm.md @@ -4,13 +4,13 @@ You can use PyCharm with pixi environments by using the `conda` shim provided by ## How to use -To get started, add `pixi-pycharm` to your pixi project. +To get started, add `pixi-pycharm` to your pixi workspace. ```bash pixi add pixi-pycharm ``` -This will ensure that the conda shim is installed in your project's environment. +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. Go to the _Add Python Interpreter_ dialog (bottom right corner of the PyCharm window) and select _Conda Environment_. @@ -30,8 +30,8 @@ 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 project" - Please make sure that this is the `conda` shim from this pixi project and not another one. +!!!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) @@ -64,7 +64,7 @@ You can now run your programs and tests as usual. ### Multiple environments -If your project uses [multiple environments](../../environments/multi_environment.md) to tests different Python versions or dependencies, you can add multiple environments to PyCharm +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) @@ -77,7 +77,7 @@ You can then specify the corresponding environment in the bottom right corner of ### Multiple pixi projects -When using multiple pixi projects, remember to select the correct _Conda Executable_ for each project 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/switching_from/conda.md b/docs/switching_from/conda.md index 657fbeb769..75ed5f0dfe 100644 --- a/docs/switching_from/conda.md +++ b/docs/switching_from/conda.md @@ -1,11 +1,11 @@ # Transitioning from the `conda` or `mamba` to `pixi` Welcome to the guide designed to ease your transition from `conda` or `mamba` to `pixi`. This document compares key commands and concepts between these tools, highlighting `pixi`'s unique approach to managing environments and packages. -With `pixi`, you'll experience a project-based workflow, enhancing your development process, and allowing for easy sharing of your work. +With `pixi`, you'll experience a workspace-based workflow, enhancing your development process, and allowing for easy sharing of your work. ## Why Pixi? -`Pixi` builds upon the foundation of the conda ecosystem, introducing a project-centric approach rather than focusing solely on environments. +`Pixi` builds upon the foundation of the conda ecosystem, introducing a workspace-centric approach rather than focusing solely on environments. This shift towards projects offers a more organized and efficient way to manage dependencies and run code, tailored to modern development practices. ## Key Differences at a Glance @@ -14,7 +14,7 @@ This shift towards projects offers a more organized and efficient way to manage |-----------------------------|---------------------------------------------------|----------------------------------------------------------------------| | Installation | Requires an installer | Download and add to path (See [installation](../index.md)) | | Creating an Environment | `conda create -n myenv -c conda-forge python=3.8` | `pixi init myenv` followed by `pixi add python=3.8` | -| Activating an Environment | `conda activate myenv` | `pixi shell` within the project directory | +| Activating an Environment | `conda activate myenv` | `pixi shell` within the workspace directory | | Deactivating an Environment | `conda deactivate` | `exit` from the `pixi shell` | | Running a Task | `conda run -n myenv python my_program.py` | `pixi run python my_program.py` (See [run](../reference/cli.md#run)) | | Installing a Package | `conda install numpy` | `pixi add numpy` | @@ -22,7 +22,7 @@ This shift towards projects offers a more organized and efficient way to manage !!! warn "No `base` environment" Conda has a base environment, which is the default environment when you start a new shell. - **Pixi does not have a base environment**. And requires you to install the tools you need in the project or globally. + **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" @@ -32,12 +32,12 @@ This shift towards projects offers a more organized and efficient way to manage ~/myenv > eval "$(pixi shell-hook)" ``` -## Environment vs Project +## Environment vs Workspace `Conda` and `mamba` focus on managing environments, while `pixi` emphasizes projects. -In `pixi`, a project is a folder containing a [manifest](../reference/pixi_manifest.md)(`pixi.toml`/`pyproject.toml`) file that describes the project, a `pixi.lock` lock-file that describes the exact dependencies, and a `.pixi` folder that contains the environment. +In `pixi`, a workspace is a folder containing a [manifest](../reference/pixi_manifest.md)(`pixi.toml`/`pyproject.toml`) file that describes the workspace, a `pixi.lock` lock-file that describes the exact dependencies, and a `.pixi` folder that contains the environment. -This project-centric approach allows for easy sharing and collaboration, as the project folder contains all the necessary information to recreate the environment. -It manages more than one environment for more than one platform in a single project, and allows for easy switching between them. (See [multiple environments](../environments/multi_environment.md)) +This workspace-centric approach allows for easy sharing and collaboration, as the workspace folder contains all the necessary information to recreate the environment. +It manages more than one environment for more than one platform in a single workspace, and allows for easy switching between them. (See [multiple environments](../environments/multi_environment.md)) ## Global environments `conda` installs all environments in one global location. @@ -64,11 +64,11 @@ bat pixi.toml ## Automated switching -With `pixi` you can import `environment.yml` files into a pixi project. (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 ``` -This will create a new project with the dependencies from the `environment.yml` file. +This will create a new workspace with the dependencies from the `environment.yml` file. ??? tip "Exporting your environment" If you are working with Conda users or systems, you can [export your environment to a `environment.yml`](../reference/cli.md#project-export-conda-environment) file to share them. @@ -83,6 +83,6 @@ Encountering issues? Here are solutions to some common problems when being used - Dependency `is excluded because due to strict channel priority not using this option from: 'https://conda.anaconda.org/conda-forge/'` This error occurs when the package is in multiple channels. `pixi` uses a strict channel priority. See [channel priority](../advanced/channel_logic.md) for more information. - `pixi global install pip`, pip doesn't work. - `pip` is installed in the global isolated environment. Use `pixi add pip` in a project to install `pip` in the project environment and use that project. + `pip` is installed in the global isolated environment. Use `pixi add pip` in a workspace to install `pip` in the workspace environment and use that workspace. - `pixi global install ` -> `import ` -> `ModuleNotFoundError: No module named ''` - The library is installed in the global isolated environment. Use `pixi add ` in a project to install the library in the project environment and use that project. + The library is installed in the global isolated environment. Use `pixi add ` in a workspace to install the library in the workspace environment and use that workspace. diff --git a/docs/switching_from/poetry.md b/docs/switching_from/poetry.md index 1451a9cbd5..8c7fd405f1 100644 --- a/docs/switching_from/poetry.md +++ b/docs/switching_from/poetry.md @@ -1,10 +1,10 @@ # Transitioning from `poetry` to `pixi` Welcome to the guide designed to ease your transition from `poetry` to `pixi`. This document compares key commands and concepts between these tools, highlighting `pixi`'s unique approach to managing environments and packages. -With `pixi`, you'll experience a project-based workflow similar to `poetry` while including the `conda` ecosystem and allowing for easy sharing of your work. +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 project 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 @@ -22,8 +22,8 @@ On top of the PyPI ecosystem, `pixi` adds the power of the conda ecosystem, allo | Lock file | `poetry.lock` | `pixi.lock` | | Environment directory | `~/.cache/pypoetry/virtualenvs/myenv` | `./.pixi` Defaults to the project folder, move this using the [`detached-environments`](../reference/pixi_configuration.md#detached-environments) | -## Support both `poetry` and `pixi` in my project -You can allow users to use `poetry` and `pixi` in the same project, they will not touch each other's parts of the configuration or system. +## Support both `poetry` and `pixi` in my workspace +You can allow users to use `poetry` and `pixi` in the same workspace, they will not touch each other's parts of the configuration or system. It's best to duplicate the dependencies, basically making an exact copy of the `tool.poetry.dependencies` into `tool.pixi.pypi-dependencies`. Make sure that `python` is only defined in the `tool.pixi.dependencies` and not in the `tool.pixi.pypi-dependencies`. @@ -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 project, 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 fa40150698..7a7a4624bb 100644 --- a/docs/tutorials/multi_environment.md +++ b/docs/tutorials/multi_environment.md @@ -1,11 +1,11 @@ # Tutorial: Using multiple environments -In this tutorial we will show you how to use multiple environments in one pixi project. +In this tutorial we will show you how to use multiple environments in one pixi workspace. ## Why is this useful? -When developing a project you often need different tools, libraries or test environments. -With pixi you can define multiple environments in one project and switch between them easily. +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. 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. @@ -13,14 +13,14 @@ Setting up different environments for these different use cases can be a hassle, This tutorial possibly uses some new terms, here is a quick overview: #### **Feature** A feature defines a part of an environment, but are not useful without being part of an environment. -You can define multiple features in one project. +You can define multiple features in one workspace. A feature can contain `tasks`, `dependencies`, `platforms`, `channels` and [more](../reference/pixi_manifest.md#the-feature-table). You can mix multiple features to create an environment. Features are defined by adding `[feature..*]` to a table in the manifest file. #### **Environment** An environment is a collection of features. Environments can actually be installed and activated to run tasks in. -You can define multiple environments in one project. +You can define multiple environments in one workspace. Defining environments is done by adding them to the `[environments]` table in the manifest file. #### **Default** Instead of specifying `[feature..dependencies]`, one can populate `[dependencies]` directly. @@ -28,15 +28,15 @@ 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 project, you can skip this step if you already have a pixi project. +We'll simply start with a new workspace, you can skip this step if you already have a pixi workspace. ```shell -pixi init project -cd project +pixi init workspace +cd workspace pixi add python ``` -Now we have a new pixi project with the following structure: +Now we have a new pixi workspace with the following structure: ``` ├── .pixi │   └── envs @@ -50,9 +50,9 @@ If no environment is specified, pixi will create or use the `default` environmen ### Adding a feature -Let's start adding a simple `test` feature to our project. +Let's start adding a simple `test` feature to our workspace. We can do this through the command line, or by editing the `pixi.toml` file. -Here we will use the command line, and add a `pytest` dependency to the `test` feature in our project. +Here we will use the command line, and add a `pytest` dependency to the `test` feature in our workspace. ```shell pixi add --feature test pytest ``` @@ -63,7 +63,7 @@ This will add the following to our `pixi.toml` file: This table acts exactly the same as a normal `dependencies` table, but it is only used when the `test` feature is part of an environment. ### Adding an environment -We will add the `test` environment to our project to add some testing tools. +We will add the `test` environment to our workspace to add some testing tools. We can do this through the command line, or by editing the `pixi.toml` file. Here we will use the command line: ```shell diff --git a/docs/tutorials/ros2.md b/docs/tutorials/ros2.md index 623e014a13..2acbd07c0e 100644 --- a/docs/tutorials/ros2.md +++ b/docs/tutorials/ros2.md @@ -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 project. +## Create a pixi workspace ```shell pixi init my_ros2_project -c robostack-staging -c conda-forge diff --git a/docs/vision.md b/docs/vision.md index 63f306de8c..e9823f0b91 100644 --- a/docs/vision.md +++ b/docs/vision.md @@ -11,7 +11,7 @@ We want to make pixi a great experience for everyone, so we have a few values th 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 project 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. +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. ## Conda diff --git a/src/cli/info.rs b/src/cli/info.rs index c74d3c89f0..ee194638f0 100644 --- a/src/cli/info.rs +++ b/src/cli/info.rs @@ -300,7 +300,7 @@ impl Display for Info { // Project information if let Some(pi) = self.project_info.as_ref() { - writeln!(f, "\n{}", bold.apply_to("Project\n------------").cyan())?; + writeln!(f, "\n{}", bold.apply_to("Workspace\n------------").cyan())?; writeln!(f, "{:>WIDTH$}: {}", bold.apply_to("Name"), pi.name)?; if let Some(version) = pi.version.clone() { writeln!(f, "{:>WIDTH$}: {}", bold.apply_to("Version"), version)?;