prefix-dev/pixi

Pixi is a cross-platform package and environment manager that unifies Conda and PyPI dependency resolution with a robust build system for source packages. It manages project workspaces by handling environment creation, task execution, and global tool installation, while supporting a wide range of build backends including C, C++, Rust, Python, R, and ROS. The system features a content-addressed cache for reproducible builds and provides a structured API for programmatic workspace manipulation and publishing.

63 changes.

The codebase underwent a major structural refactor, splitting the monolithic application into a modular workspace of specialized crates for build backends, configuration, and manifest handling. This architectural shift was accompanied by the removal of legacy CLI commands and project structures, while simultaneously introducing a comprehensive suite of new examples covering ROS, OpenCV, Jupyter, and various language bindings to demonstrate the platform's expanded capabilities.

77 changes.

This period focused on replacing the core execution engine with a new CommandDispatcher architecture that manages builds, solves, and installations via content-addressed caching and concurrency control. The CLI was significantly restructured, introducing dedicated crates for global environments, workspace management, and API abstractions, while extracting core logic into modular components like pixi\_core and pixi\_task.

37 changes.

This period focused on implementing the pixi-build API version 7, introducing a new compute engine for dependency resolution and a modular backend system supporting C, C++, Rust, Python, Mojo, R, and ROS. The work included rewriting build backends to track exact inputs, adding Git LFS support, and enabling cross-compilation through explicit build-platform tracking. Additionally, new CLI commands like \pixi list\ and \pixi publish\ were added, alongside features for conditional dependencies and formatting-preserving TOML editing.

A new example project has been added to showcase building a C++ application with SDL2 using Pixi. The example includes a CMakeLists.txt configuration and a main.cc source file that renders a red square on an 800x600 window, which moves to follow the mouse cursor. The pixi.toml defines a build environment with CMake, Ninja, and SDL2 dependencies, providing tasks to configure, build, and run the executable across Windows, Linux, and macOS platforms.

examples/cpp-sdl · high confidence

This location introduces a new Python library example that demonstrates using GCP keyring for authentication. The package includes a simple \hello\ function and corresponding tests, managed via a pixi environment with a locked dependency set (including Python 3.13, rich, and keyrings.google-artifactregistry-auth).

examples/python-library-gcp-keyring · high confidence

A new JupyterLab example has been added to the repository, providing a set of interactive Python notebooks demonstrating scientific computing capabilities. The example includes a .gitignore file to exclude local environment artifacts and three notebooks: 'Factoring.ipynb' for polynomial factoring using SymPy, 'Image\_Browsing.ipynb' for image dataset exploration using scikit-learn, and 'LorenzDifferentialEquations.ipynb' for visualizing chaotic systems using NumPy and SciPy.

examples/jupyterlab · high confidence

A new demo example has been added to the examples/lightgbm directory that demonstrates how to build and evaluate a LightGBM classification model using the Wisconsin Breast Cancer dataset. The example includes a Python script (main.py) that loads the data, trains the model, and prints accuracy and confusion matrix metrics, along with a pixi.toml configuration to manage dependencies (lightgbm 4.1.0, pandas, scikit-learn) and a README with usage instructions.

examples/lightgbm · high confidence

The \examples/opencv\ directory now includes a complete, runnable example for computer vision tasks using OpenCV and pixi. Users can run \pixi run start\ to execute a webcam capture script that detects faces using a Haar cascade classifier, or \pixi run calibrate\ to perform camera calibration using a chessboard pattern. The example manages its own environment via \pixi.toml\ (depending on OpenCV 4.10.0 and Python 3.10) and includes a \.gitignore\ to exclude generated images and downloaded cascade files.

examples/opencv · high confidence

This change introduces a new example project in the \examples/pypi\ directory that demonstrates how to manage Python packages alongside Conda dependencies using Pixi. The example includes a \pixi.toml\ workspace configuration specifying platforms (Windows, Linux, macOS) and dependencies such as NumPy, SciPy, TensorFlow, and Flask, along with activation scripts for setting environment variables. It also provides a lock file (\pixi.lock\) and a Python script (\pycosat\_example.py\) to verify that sdist packages can be resolved and executed correctly.

examples/pypi · high confidence

A new example project has been added to the \examples/qgis\ directory that demonstrates using QGIS with real-time earthquake data. The example includes a \pixi.toml\ configuration to manage dependencies (QGIS, GeoPandas, Python) and a \get\_data.py\ script that downloads the latest weekly earthquake feed from the USGS. Users can run the \get-data\ task to fetch the data and the \start\ task to launch QGIS with the loaded earthquake layer.

examples/qgis · high confidence

Users can now run an R example in the \examples/r\ directory that generates a scatterplot of fuel efficiency versus weight using the \ggplot2\ library. The example is managed by \pixi\, which provides tasks to start the R interpreter, create the plot, and launch RStudio on Linux and macOS platforms.

examples/r · high confidence

This change introduces a new \examples/turtlesim\ directory that provides a complete, reproducible setup for running the ROS turtlesim simulation using Pixi. It includes a \pixi.toml\ workspace configuration defining two environments: one for ROS 2 Humble (using the \robostack-humble\ channel) and one for ROS 1 Noetic (using the \robostack-noetic\ channel). The example provides tasks to start the turtlesim node, teleoperation, and RViz visualization, along with Python scripts (\turtle\_marker\_viz\_ROS1.py\ and \turtle\_marker\_viz\_ROS2.py\) that publish turtle pose markers to RViz. A \pixi.lock\ file ensures deterministic dependency resolution, and a \.gitignore\ excludes local environment artifacts.

examples/turtlesim · high confidence

Users can now run \pixi list\ to view installed packages in their workspace environments. This new command resolves the lock file for a specific platform and environment, then outputs a table of Conda and PyPI packages including details such as name, version, size, source, and requested specifications. It supports filtering by regex and showing only explicitly declared dependencies.

_crates/pixi\api/src/workspace/list · high confidence

A new example project has been added to \examples/ctypes-factorial\ that demonstrates packaging C and Python libraries together, compiling C code via Pixi tasks, and using conditional task execution. The example includes a C implementation for calculating large factorials, a Python script using \ctypes\ to call it, and a \pixi.toml\ configuration that sets up platform-specific compilers (gcc, clang, m2w64-gcc) and tasks to build and run the calculation.

examples/ctypes-factorial · high confidence

This change introduces a new example project that demonstrates how to use Pixi to manage a local Python package as an editable dependency while specifying extras. The example includes a sample package (\package\_with\_extras\) and a \pixi.toml\ configuration that installs the package from a local path in editable mode with the \cli\ and \color\ extras enabled, alongside standard conda-forge channels and Python 3.12.

examples/editable-with-extras · high confidence

The \examples/pixi-build/recursive-run-dependencies\ directory has been added to demonstrate how source packages can depend on other source packages. The example workspace defines a \root\ package that lists a \depend\ package as a run dependency, showing that installing the default environment resolves and installs both packages recursively.

examples/pixi-build/recursive-run-dependencies · high confidence

Added a new example in the \examples/geos-rs\ directory that demonstrates how to use the \geos-rs\ Rust crate to interact with the GEOS geometry library. The example includes a \pixi.toml\ workspace configuration and a \pixi.lock\ file that pin specific versions for Rust (1.87.0), the \geos\ crate (\>=3.13.1), and system dependencies like \pkg-config\ across Linux, macOS, and Windows platforms. The accompanying \src/main.rs\ code showcases core geometric operations, including creating geometries from WKT, calculating area, checking intersections and containment, buffering shapes, and computing centroids.

examples/geos-rs · high confidence

A new minimal example project has been added to the \examples/pixi-build/dev\ directory to demonstrate building C++ applications with pixi-build. The example uses CMake to compile a simple C++ application that links against SDL2, and includes a \pixi.toml\ configuration that sets up the pixi-build-cmake backend, defines build and host dependencies (including CMake and Python), and specifies run dependencies like \bat\. A corresponding \pixi.lock\ file is also included to ensure reproducible builds across Linux, macOS, and Windows platforms.

examples/pixi-build/dev · high confidence

A new example project has been added to demonstrate PyPI source dependencies. This minimal project includes a Python module that prints a greeting and implements version detection using importlib.metadata, providing a concrete reference for users setting up similar source-based package configurations.

examples/pypi-source-deps/minimal-project · high confidence

A new example project has been added to demonstrate how to use \pixi\ to generate explicit conda environment specifications and \constructor\ to build platform-specific, offline-ready installers. The example includes a \pixi.toml\ workspace configuration with tasks for building installers on Linux, macOS, and Windows, along with a \construct.yaml.in\ template and a \pixi.lock\ file pinning the necessary dependencies like \constructor\ and \mamba\.

examples/constructor-minimal · high confidence

The \examples/multi-machine\ directory now provides a reference project demonstrating how to configure Pixi workspaces with multiple target platforms. The \pixi.toml\ defines custom platform features for CUDA-enabled Windows and Linux environments, as well as macOS with Apple Silicon support. It includes tasks that conditionally run different scripts (e.g., \train.py\, \test.py\) with specific arguments like \--cuda\ or \--mlx\ depending on the active environment, and adds the \mlx\ library as a dependency for the macOS target. Supporting files include \.gitignore\ and \.gitattributes\ for proper repository hygiene, and a generated \pixi.lock\ file reflecting the resolved dependencies for all defined platforms.

examples/multi-machine · high confidence

This location introduces the \polyglot-particles\ example, a pixi-build workspace that demonstrates wiring together packages written in C, C++, Rust, and Python around a single C ABI. It includes the workspace manifest (\pixi.toml\) with centralized dependencies, a lockfile (\pixi.lock\), and sub-packages for the core C library, C++ emitters/modifiers, Python bindings via pybind11 and PyO3, an SDL2 visualizer, and a Python orchestration kit. Users can run \pixi run demo\ to build and visualize a particle scene or \pixi run list\ to inspect the registered components.

examples/pixi-build/polyglot-particles · high confidence

A new example project has been added to \examples/pybind11\ that demonstrates how to compile pybind11 modules using Pixi and scikit-build-core. The example includes a C++ source file (\src/main.cpp\) exposing a simple \add\ function, a CMake build configuration, and a Pixi environment lockfile (\pixi.lock\) that pins specific versions of build tools (such as CMake 3.30, GCC/Clang compilers, and Python 3.11) to ensure reproducible builds across Linux, macOS, and macOS ARM platforms.

examples/pybind11 · high confidence

The pixi\_api crate now exposes a reinstall capability for workspaces. Users can trigger a reinstallation of specific packages within selected environments (or all/default environments) via the new \reinstall\ function and \ReinstallOptions\ struct, which supports targeting a specific platform and respects the workspace's lock file usage settings.

_crates/pixi\api/src/workspace/reinstall · high confidence

A new C++ example application has been added to the examples/develop/cpp-sdl directory. This application demonstrates basic SDL functionality by creating an 800x600 window and rendering a red square that follows the mouse cursor. It includes a help flag (-h) for usage instructions and handles window creation, rendering, and event loops for quitting.

examples/develop/cpp-sdl · high confidence

A new example project demonstrating how to build a C++ application using SDL2 with Pixi. The example includes a CMakeLists.txt configuration, a main source file that renders a window with a mouse-following square, and a pixi.toml workspace setup that defines the pixi-build-cmake backend, host dependencies for SDL2, and tasks to configure, build, and run the executable.

examples/pixi-build/cpp-sdl · high confidence

A new shim module has been introduced in the \reqwest\_middleware\_shim\ package. This module re-exports all public items from its internal \inner\ module, effectively acting as a pass-through layer for the underlying reqwest middleware implementation.

_patches/reqwest\_middleware\shim · high confidence

Pixi now provides a dedicated \pixi\_auth\ crate that centralizes the creation and configuration of authentication storage. Users benefit from a unified mechanism that respects pixi's configuration settings, specifically allowing an \authentication\_override\_file\ to be loaded and prioritized before default system keyring or credential storage. This simplifies authentication setup by automatically handling environment variables like \RATTLER\_AUTH\_FILE\ and ensuring the correct backend order for credential resolution.

_crates/pixi\auth · high confidence

The \UvResolutionContext\ in \crates/pixi\_uv\_context\ now exposes configuration for HTTP timeout, retry count, and concurrency settings, allowing users to tune network behavior for PyPI resolution and installation. Timeout and retry values are read from environment variables (\UV\_HTTP\_TIMEOUT\, \UV\_REQUEST\_TIMEOUT\, \HTTP\_TIMEOUT\, and \UV\_HTTP\_RETRIES\), while concurrency is derived from Pixi config or \UV\CONCURRENT\\*\ environment variables. This change enables better control over network stability and performance during package operations.

_crates/pixi\_uv\context · high confidence

This change adds Python source files for the \pixi\_build\ getting started, python, workspace, and workspace\_variants documentation examples, introducing a \Person\ dataclass and \rich\ table display logic (with \cpp\_math\ integration in workspace variants). It also introduces a new \schema/model.py\ file defining the canonical Pydantic schema for \pixi.toml\ (including \CudaTable\, \WorkspacePlatform\, and platform enums), adds a \scripts/build\_pgo.py\ script for Profile-Guided Optimization builds, and a \scripts/release\_backends.py\ script for managing backend releases. Finally, it adds test infrastructure including \tests/scripts/run-all-examples.py\, \tests/wheel\_tests/read\_wheels.py\, and \tests/wheel\_tests/record\_results.py\ to support example execution and wheel testing.

python · high confidence

The new \pixi\_toml\_edit\ crate provides helpers for editing TOML manifests that preserve the original document's style, including indentation, line breaks, and comments. When adding or removing entries in arrays or inline tables, the tool now keeps comments attached to their respective lines, maintains multiline formatting, and avoids flattening single-line containers. This ensures that user-written formatting and annotations in configuration files remain intact after updates.

_crates/pixi\_toml\edit · high confidence

The \pixi-git\ crate has been rewritten to support Git Large File Storage (LFS) and offline resolution. Users can now opt into fetching LFS objects for git dependencies via the \lfs\ field in the manifest (or the deprecated \PIXI\_GIT\_LFS\ environment variable); when LFS is not requested, pointer files are left in the checkout. Additionally, the \--offline\ flag is now respected for git sources, preventing network access and failing fast if the revision is not already cached. The implementation also improves credential handling by caching and reusing authentication for git URLs and disables terminal prompts to avoid hangs on SSH passphrase errors.

_crates/pixi\git · high confidence

The \pixi global\ functionality has been moved into a dedicated \pixi\_global\ crate, introducing a new modular structure for managing global environments. This change includes dedicated modules for handling shell completions (Bash, Zsh, Fish), a reworked terminal report system for clearer status output, and a new trampoline mechanism that uses compressed binaries and hardlinks to manage global executables. Additionally, the \pixi global list\ command now supports a \--json\ flag for machine-readable output, and the installation logic has been updated to handle environment activation variables and \CONDA\_PREFIX\ more robustly.

_crates/pixi\global/src · high confidence

Pixi now uses a new CommandDispatcher component to manage and synchronize operations across conda environments. This dispatcher wraps a compute engine to handle task deduplication, caching, and dependency tracking for core workflows like environment solving, source metadata fetching, and package installation. It centralizes shared resources such as the repodata gateway, package caches, and network clients, while introducing configurable concurrency limits via semaphores for git checkouts, URL fetches, conda solves, and backend builds. Users benefit from more robust error handling, including explicit cancellation support, and improved visibility through granular, per-operation reporters.

_crates/pixi\_command\_dispatcher/src/command\dispatcher · high confidence

The \pixi\_build\_types\ crate now exposes the data structures for the new \conda/build\_v1\ and \conda/outputs\ API methods, alongside the existing \initialize\ and \negotiateCapabilities\ procedures. This adds support for v1-specific features such as channel configuration, extra dependency groups, run exports, and structured input glob sets, enabling backends to negotiate and utilize the updated build protocol.

_crates/pixi\_build\types/src/procedures · high confidence

A new \PythonStatus\ type has been added to the \pixi\_python\_status\ crate to describe how the Python interpreter in a prefix changes between transactions. This allows the system to determine whether site-packages need to be recreated or cleaned up when updating PyPI packages by detecting if the interpreter was added, removed, changed, or remained unchanged.

_crates/pixi\_python\status · high confidence

Pixi now supports building R packages via a new \pixi-build-r\ backend. This adds a build system that parses R DESCRIPTION files to resolve dependencies (converting them to \r-\*\ conda packages), auto-detects native code requirements to inject C/C++/Fortran compilers, and generates platform-specific build scripts for both Unix and Windows. Users can configure the backend via \RBackendConfig\ to specify extra \R CMD INSTALL\ arguments, environment variables, input globs, and conda channels.

_crates/pixi\_build\r/src · high confidence

The new \pixi\_spec\ crate centralizes the definition of package specifications (\PixiSpec\), supporting binary packages (from channels, URLs, or local paths) and source packages (from paths, URLs, or Git repositories). It introduces structured types for Git dependencies with optional LFS fetching, development source specifications for local packages, and match-spec selectors (version, build, extras, flags) that can be applied to source outputs. The crate also defines the \ExcludeNewer\ configuration for controlling package cutoffs by timestamp or duration, and provides the \Pin\ type to resolve \pin\_compatible\ and \pin\_subpackage\ expressions into concrete version constraints.

_crates/pixi\spec · high confidence

Added a new \pixi\_docs\ crate that automatically generates Markdown documentation for the Pixi CLI commands and updates the Zensical navigation configuration. This tool extracts command metadata using Clap, creates organized reference pages, and maintains the documentation site's table of contents, replacing the previous manual or ad-hoc documentation generation process.

_crates/pixi\docs · high confidence

The \pixi\_pty\ crate has been added to provide a dedicated, cross-platform (Unix) implementation for managing pseudo-terminal sessions. This new component exposes \PtyProcess\ and \PtySession\ structs that handle process creation, raw terminal mode, and I/O forwarding. It includes specific logic to handle terminal window resizing via SIGWINCH and implements a 'buffer bypass' mechanism to immediately forward DAQ (Device Attribute Query) sequences, preventing hangs with newer shells like fish 4.1.0. This change isolates the low-level PTY management logic from the main application code.

_crates/pixi\pty · high confidence

A new \solve\_conda\ module has been added to the \pixi\_command\_dispatcher\ crate, introducing the \SolveCondaEnvironmentSpec\ struct and its \solve\_on\_blocking\_pool\ method. This change centralizes the input specification and execution of conda environment solves within the dispatcher, handling source and binary package specifications, constraints, and repodata to produce a resolved set of \PixiRecord\s on a background thread.

_crates/pixi\_command\_dispatcher/src/solve\conda · high confidence

Adds the \pixi\_progress\ crate, providing a centralized library for managing console progress indicators. It includes a \println!\ macro that safely suspends active progress bars to prevent output interference, a global \MultiProgress\ instance for coordinated updates, and utilities for styling bars (including byte-rate tracking and spinner animations). The crate also integrates with terminal emulators (Windows Terminal, iTerm2, WezTerm) via OSC 9;4 sequences to display progress in the title bar or taskbar, and offers a \ProgressBarPlacement\ API for precise ordering of multiple progress bars.

_crates/pixi\progress · high confidence

Added a new module in the command dispatcher to query build backends for dev source metadata, enabling the system to retrieve all outputs from a source and create corresponding DevSourceRecords. This change introduces support for handling dev dependencies by fetching metadata via the \conda/outputs\ procedure, with specific error handling for unsupported protocols, cycles, and missing packages (including suggestions for similar package names).

_crates/pixi\_command\_dispatcher/src/dev\_source\metadata · high confidence

The \pixi\_global\ crate now manages a structured global manifest that defines environments, channels, and dependencies. Users can now define environments with specific channels and dependencies, including support for inline package definitions to customize build backends. The manifest parser enforces strict naming conventions for environments and detects duplicate exposed names or invalid keys, providing clear error messages for configuration issues.

_crates/pixi\global/src/project · high confidence

Added a new in-memory build backend interface in the \pixi\_build\_frontend\ crate, allowing build backends to run completely in memory without external tools or processes. This interface, consisting of traits like \InMemoryBackend\ and \InMemoryBackendInstantiator\ along with a \BoxedInMemoryBackend\ wrapper, is designed primarily to facilitate testing by enabling backend simulation and mocking capabilities.

_crates/pixi\_build\_frontend/src/backend/in\memory · high confidence

A new \pixi\_build\_discovery\ crate has been added to handle the automatic detection of build backends for source trees. It supports discovering backends via \pixi.toml\, \recipe.yaml\, and ROS \package.xml\ manifests, allowing users to build projects without manually specifying the backend tool. The crate defines \BackendSpec\ and \CommandSpec\ types to configure how backends (such as \pixi-build-rattler-build\ or \pixi-build-ros\) are instantiated, including resolving relative paths and managing conda environment requirements.

_crates/pixi\_build\discovery/src · high confidence

A new \passthrough\ in-memory build backend has been added to the \pixi\_build\_backend\_passthrough\ crate. This backend forwards the project model to the \conda/outputs\ API without modification, allowing users and developers to test and debug the build pipeline without performing actual compilation. It also includes a development task (\xtask generate-schema\) to keep the \pixi\_build\_api.json\ schema file synchronized with the \ProjectModel\ definition.

_crates/pixi\_build\_backend\passthrough · high confidence

A new \pixi\_api\ crate has been added to provide a structured abstraction for interacting with Pixi workspaces. It exposes a \WorkspaceContext\ for managing workspace properties (such as name, description, and preview flags), handling environment activations (listing, adding, and removing scripts), and performing dependency operations (adding and removing conda and PyPI packages). The crate also includes a \DefaultContext\ for package searching and defines an \Interface\ trait to allow consumers to inject custom logic for CLI interactions like progress reporting, user confirmation, and status messages.

_crates/pixi\api/src · high confidence

A new \pixi\_build\_type\_conversions\ crate has been added to handle the conversion of internal \pixi\_spec\ types into the wire-format types used by \pixi\_build\_types\. This module exposes functions to convert package specifications (including source specs with Git LFS support and binary specs) and dependency maps, ensuring that the build system receives correctly formatted data without \pixi\_build\_types\ depending directly on \pixi\_spec\.

_crates/pixi\_build\_type\conversions/src · high confidence

Added the new \crates/pypi\_modifiers\ library, which centralizes the logic for determining Python marker environments and generating platform-specific wheel tags. This module exposes functions to compute \MarkerEnvironment\ values (including \sys\_platform\, \platform\_machine\, and implementation details) and to generate \uv\_platform\_tags::Tags\ for Linux (manylinux/musllinux), macOS, and Windows. It handles architecture mapping, libc family detection (glibc/musl), and Python version parsing, providing a consistent API for downstream components to resolve PyPI compatibility.

_crates/pypi\modifiers · high confidence

The pixi build system now uses the rattler-build backend, allowing users to specify a custom recipe file via the \recipe\ configuration option and enable experimental features (such as multi-output caching) via the \experimental\ flag. The backend also supports target-specific overrides for \extra\_input\_globs\ while enforcing that \experimental\ and \recipe\ settings remain global across all targets.

_crates/pixi\_build\_rattler\build/src · high confidence

A new \pixi\_compute\_network\ crate has been added to centralize access to shared network infrastructure, such as the HTTP client used for downloading packages. It also introduces an offline mode flag within the engine's data store, allowing the system to detect when it is running offline and enabling solves to restrict themselves to locally available packages.

_crates/pixi\_compute\network · high confidence

Added a new standalone trampoline binary (with build and compression scripts) that allows running executables installed via \pixi global install\. The trampoline reads a JSON configuration file to set environment variables, prepend specific paths to the PATH variable (handling missing PATH or base path differences), and execute the target executable, providing a lightweight, dependency-free way to launch global tools.

trampoline · high confidence

The pixi build frontend now includes a new JSON-RPC module that provides a stdio-based transport layer for communicating with child processes. This change adds a \Sender\ and \Receiver\ implementation that wraps standard input and output streams, allowing the build system to send and receive JSON-RPC messages over stdin/stdout. This enables the \pixi build\ command to interact with external build tools via a standardized JSON-RPC protocol, facilitating the preview of workspace-aware build operations.

_crates/pixi\_build\frontend/src/jsonrpc · high confidence

The pixi build frontend now supports overriding build backend tools via environment variables (PIXI\_BUILD\_BACKEND\_OVERRIDE\_ALL and PIXI\_BUILD\_BACKEND\_OVERRIDE), allowing users to specify custom executable paths or rely on system-installed tools. It also introduces a unified Tool abstraction that distinguishes between isolated tools (installed in their own environment with activation scripts) and system tools, providing a consistent interface for invoking build backends.

_crates/pixi\_build\frontend/src · high confidence

The \pixi\_path\ crate has been added to provide compile-time guarantees for path handling. It introduces new types such as \AbsPath\, \AbsPathBuf\, \AbsPresumedDirPath\, and \AbsPresumedFilePath\ to ensure paths are absolute and to distinguish between file and directory intents without implicit filesystem checks. Additionally, it includes a \normalize\ module with functions like \normalize\_std\ and \normalize\_typed\ to lexically resolve \.\ and \..\ components in paths without accessing the filesystem.

_crates/pixi\path · high confidence

A new \BarrierCell\ type has been added to the \barrier\_cell\ crate, providing a synchronization mechanism that allows multiple waiters to block until a single value is set. The implementation uses a \parking\_lot::Mutex\ to manage internal state and a \tokio::sync::broadcast\ channel to efficiently notify all waiting tasks when the value becomes available via the \set\ method. The cell ensures that \set\ can only be called once, returning a \SetError::AlreadySet\ if attempted again, and provides an \into\_inner\ method to consume the cell and retrieve the value if it has been initialized.

_crates/barrier\cell · high confidence

The workspace add module now exposes \add\_conda\_deps\, \add\_pypi\_deps\, \remove\_conda\_deps\, and \remove\_pypi\_deps\ functions, allowing users to programmatically modify workspace dependencies. These endpoints support specifying features, platforms, and lock file usage, and handle git and path-based source dependencies when the \pixi-build\ preview flag is enabled.

_crates/pixi\api/src/workspace/add · high confidence

Added a new \examples/docker\ directory that demonstrates how to use Pixi's solve-groups and per-environment editability features to build Docker images. The example configures a \default\ environment with editable local dependencies for development and a \prod\ environment with non-editable dependencies for production, ensuring both use identical dependency versions. It includes a multi-stage Dockerfile that builds a minimal production image using only the \prod\ environment, along with supporting files like \docker-compose.yml\, \pyproject.toml\, and a \pixi.lock\ file.

examples/docker · high confidence

Added a new example in the \examples/llama-index-inference\ directory that demonstrates running local LLM inference using \llama-index\ and \llama.cpp\. The example includes a Python script (\inference.py\) that downloads and runs the Mistral-7B-Instruct-v0.3 model, along with a \pixi.toml\ workspace configuration to manage dependencies for macOS ARM and Linux AMD64 platforms.

examples/llama-index-inference · high confidence

The \examples/rerun\_example\ directory now includes a complete Pixi-managed environment (pixi.toml, pixi.lock) and three new demonstration scripts. The \dna\_example.py\ script visualizes a 3D DNA abacus structure with animated beads. The \force\_driven\_lock\_file\_graph.py\ script reads a \pixi.lock\ file and renders its package dependency graph as an interactive 3D force-directed layout. Additionally, the \lidar/\ and \nuscenes\_dataset/\ subdirectories provide examples for visualizing LiDAR point clouds and multi-sensor nuScenes autonomous driving data (including cameras, radar, and GPS) using the Rerun SDK.

_examples/rerun\example · high confidence

A new \pixi\_url\ crate has been added to provide utilities for downloading and unpacking archives from arbitrary URLs. This includes a \UrlSource\ that manages the full lifecycle of fetching an archive, verifying SHA256 and MD5 checksums, and extracting supported formats (tar, gzip, bzip2, xz, zstd, zip, 7z) into a local cache. The implementation features a \UrlResolver\ to track precise hashes for reproducible builds, progress reporting via a \ProgressHandler\ trait, and concurrent download protection using file locks.

_crates/pixi\url/src · high confidence

Users can now explore a new example in the WASM JupyterLite environment that demonstrates Matplotlib functionality. This addition includes a sample notebook (Matplotlib.ipynb) that renders plots within the browser-based Jupyter interface, allowing for interactive data visualization without requiring a local Python installation.

examples/wasm-jupyterlite/files · high confidence

Added Windows batch templates (bld\_ament\_cmake.bat, bld\_ament\_python.bat, bld\_catkin.bat) to support building ROS packages on Windows. These scripts configure build environments for MSVC, handle Python path resolution, and manage installation manifests to ensure clean incremental builds.

_crates/pixi\_build\ros/templates · high confidence

Users can now use the \pixi workspace requires-pixi\ command group to manage the minimum pixi version required by a workspace. This includes \get\ to print the current requirement, \set \<version\>\ to update it, \unset\ to remove it, and \verify\ to check if the current pixi installation satisfies the requirement. The \verify\ command provides specific guidance, suggesting \pixi self-update --version\ if the installed version is too old and the self-update feature is available.

_crates/pixi\_cli/src/workspace/requires\pixi · high confidence

A new \pixi workspace\ command group is introduced to manage workspace configuration directly from the CLI. This includes subcommands to manage activation scripts and environment variables (\activation\), workspace channels (\channel\), and dependencies (\dependencies\). It also provides commands to manage workspace metadata such as the name and description, as well as structural elements like environments, features, and platforms. Additional capabilities include managing preview flags (\preview\), exporting workspace state (\export\), and registering workspaces in a global registry (\register\).

_crates/pixi\cli/src/workspace · high confidence

The \crates/pixi\_config\ crate introduces a unified configuration layer that manages TLS root certificate selection (defaulting to system certificates, with support for webpki and legacy aliases), proxy settings derived from environment variables, and environment activation behavior (including detached environments and shell completion sourcing). It also defines concurrency limits, S3 storage options, and build package formats, providing the structural foundation for how Pixi loads and merges global and project-local configuration files.

_crates/pixi\config · high confidence

The \pixi\_command\_dispatcher\ now exposes a set of compute-engine keys in \src/keys\ to structure the source-package solve path. \SolvePixiEnvironmentKey\ orchestrates the top-level environment solve, delegating to \ResolveSourcePackageKey\ which pins source locations, checks out code, and fans out to \SourceMetadataKey\ for backend metadata. \SourceMetadataKey\ queries the build backend and returns \CondaOutput\s, which are then assembled into \SourceRecord\s by \assemble\_source\_record\ in \resolve\_source\_record.rs\, handling nested build and host environment solves. \SolveCondaKey\ performs the binary package resolution, while \SourceBuildKey\ handles building source records into \.conda\ artifacts with two-tiered caching. Supporting keys include \BackendBinaryFingerprintKey\ for content-based backend identification and \InputGlobSetWalkKey\ for efficient, deduplicated filesystem walks used in cache freshness checks.

_crates/pixi\_command\dispatcher/src/keys · high confidence

The \pixi\_reporters\ crate has been extracted to centralize and standardize terminal progress reporting across the CLI. This change introduces a \TopLevelProgress\ coordinator that wires together specific reporters for conda solving, package installation, repodata fetching, and git source checkouts, ensuring users see consistent, granular progress bars for these operations. It also adds structured handling for channel notices (including deduplication and retention logic) and formats release notes with syntax highlighting while skipping contributor and download sections.

_crates/pixi\reporters · high confidence

Added a new example project (\cuda\_probe\) that demonstrates the \if(...)\ conditional dependency syntax in the \\[package\]\ section of \pixi.toml\. This example shows how to conditionally include build dependencies (specifically CUDA toolchain packages) only on Linux and Windows platforms, allowing the same source code to build a CUDA-enabled binary on supported platforms and a CPU-only binary on macOS.

examples/pixi-build/conditional-dependencies · high confidence

The \pixi\_glob\ crate now exposes \GlobHash\ and \GlobHashCache\ to compute deterministic SHA-256 hashes of files matching glob patterns (normalizing line endings and paths for cross-platform consistency) and \GlobModificationTime\ to find the newest file modification time among matches. These utilities enable build systems to detect file changes accurately and cache hash computations efficiently, reducing unnecessary rebuilds.

_crates/pixi\glob/src · high confidence

The installation process now uses dedicated \install.ps1\ (Windows) and \install.sh\ (Unix/Linux/macOS) scripts that automatically prepend a 'v' to version numbers if missing, support custom download URLs via the \PIXI\_DOWNLOAD\_URL\ environment variable, and mask credentials in printed URLs for security. The scripts also respect \PIXI\_HOME\ and \PIXI\_NO\_PATH\_UPDATE\ environment variables, allow architecture override via \PIXI\_ARCH\ (install.sh) or automatic detection (install.ps1), and handle authentication via \.netrc\ files or the \NETRC\ environment variable during download.

install · high confidence

The new \pixi\_script\_shell\ crate introduces a lightweight shell environment specifically for \conda-script\ entrypoints. It provides a parser and executor that support whitespace splitting, single and double quotes, \${VAR}\ substitution, recursive \$(...)\ command substitution, and \&&\ command sequencing. Unlike a full system shell, this mini-shell explicitly rejects pipes, redirects, semicolons, backticks, and environment variable assignments, ensuring scripts run in a controlled, predictable manner without spawning a system shell process.

_crates/pixi\_script\shell · high confidence

The pixi-build backend crate has been restructured into a modular library providing a shared CLI, protocol definitions, and an intermediate backend that generates recipes for rattler-build. Users benefit from automatic default compiler variants (e.g., vs2022 on Windows, clang on macOS) and CUDA support, as well as explicit support for Git Large File Storage (LFS) in source dependencies, which is now propagated through the build configuration.

_crates/pixi\_build\backend/src · high confidence

An example project has been added to \examples/pixi-build/v3\ that showcases pixi-build v3 capabilities. The \pixi.toml\ configures a Rust build backend and defines environments (\all\, \py\, \rust\) that utilize package extras and flags. It also demonstrates conditional dependencies, where the \bat\ package is included only when the Python version is 3.10 or higher, and provides a lockfile reflecting these platform-specific resolutions.

examples/pixi-build/v3 · high confidence

The \pixi\_compute\_engine\ crate introduces a new dependency-resolution engine featuring synchronous cycle detection, scoped cycle recovery via \with\_cycle\_guard\, and parallel dependency combinators (\compute2\, \compute3\, \compute\_join\). It provides a builder API for configuring shared data and spawn hooks, and includes utilities like \AnyKey\ for type-erased key handling and \AbortOnDrop\ for task lifecycle management.

_crates/pixi\_compute\engine · high confidence

The \pixi\_utils\ crate has been introduced to centralize shared utilities. It adds atomic file writing that preserves existing file permissions and falls back to direct writes when necessary, ensuring files are never left in a partially-written state. Environment installation is now protected by a cross-process exclusive lock that detects interrupted installs and prevents redundant work. Additionally, a reproducibility feature stamps \.pixi/\ directory modification times based on \SOURCE\_DATE\_EPOCH\ to produce bit-identical layouts across runs. The crate also includes utilities for parsing conda environment files, hashing environment specs for caching, and managing executable paths.

_crates/pixi\utils/src · high confidence

Added a new example under examples/pixi-build/polyglot-particles that demonstrates a particle system built across multiple languages. The core logic is implemented in C (pool management, step, and snapshot), with C++ bindings providing emitter and modifier implementations (Cone, Burst, Gravity, Drag) exposed via pybind11. A Rust module adds a Ring emitter and Vortex/Attractor modifiers, also exposed to Python. A Python package (particle\_cpp\_py) exposes these C++ classes, and a separate view module (particle\_view) uses SDL2 to render the particle pool in a window, allowing users to run and visualize the polyglot particle simulation.

(repo-wide) · high confidence

The repository now includes a comprehensive suite of new scripts to manage the release process and build artifacts. This includes \release.py\ for version bumping and changelog generation, \create\_tag.py\ and \create\_release.py\ for managing Git tags and publishing GitHub releases with checksums, and \build\_options.py\ for configuring target-specific build flags (such as static CRT linking on Windows and jemalloc settings on Linux). Platform-specific packaging is handled by \build\_msi.py\ for Windows installers, \sign\_macos.py\ for macOS code signing and notarization, and \package\_binary.py\ for creating archives. Additional utilities include \install.py\ for local installation, \local\_patch.py\ for managing local dependencies, \activate.sh\ for build environment setup, and documentation helpers like \generate\_llms.txt\, \generate\_redirects.py\, and \stage\_docs\_files.py\ to support the new Zensical documentation site.

scripts · high confidence

Added a new example project in examples/simple-calculator that showcases the task argument feature. The example includes a Python calculator module with basic arithmetic operations and a pixi.toml configuration defining tasks like 'calculate' that accept dynamic arguments (operation, number1, number2) and a 'greeting' task with named parameters, illustrating how users can pass variables to tasks at runtime.

examples/simple-calculator · high confidence

Users can now export their pixi workspace configurations into standard conda formats using two new subcommands: \pixi workspace export conda-environment\ generates a \environment.yaml\ file (supporting options to target specific platforms/environments, customize the environment name, exclude PyPI dependencies, or freeze versions from the lock file), and \pixi workspace export conda-explicit-spec\ generates explicit environment spec files for reproducible conda-only installations (with options to ignore PyPI or source package errors). These commands are registered under the \pixi workspace export\ command group in the CLI.

_crates/pixi\cli/src/workspace/export · high confidence

The \pixi\_api\ crate now includes a dedicated \workspace/init\ module that handles the creation of new Pixi workspaces. This change introduces support for initializing projects in three manifest formats: the native \pixi.toml\, \pyproject.toml\ (either new or extending an existing one), and \Mojoproject\. The implementation allows users to bootstrap workspaces from environment files, configure specific platforms and channels, and automatically generate necessary source control files like \.gitignore\ and \.gitattributes\ based on the selected SCM provider (GitHub, GitLab, or Codeberg).

_crates/pixi\api/src/workspace/init · high confidence

The \pixi\_api\ crate now exposes a comprehensive set of functions for managing workspace configuration, including listing, adding, and removing environments; managing channels with priority and lockfile updates; editing workspace platforms (including auto-detection and reordering); manipulating activation scripts and environment variables; managing features and their dependencies; and enabling or disabling preview flags. These changes allow external tools and CLI commands to programmatically modify the workspace manifest and trigger necessary lockfile resolutions.

_crates/pixi\api/src/workspace/workspace · high confidence

This release introduces the ability to run \conda-script\ files directly from HTTP or HTTPS URLs (including GitHub Gists) via \pixi run --script\, allowing Pixi to download and cache the script environment without a local file. It also explicitly tracks the platform of derived environments, keeping nested derived environments on the build platform, and adds a new \PrefixPlatformMismatchError\ for source build prefixes. Additionally, the release improves TOML formatting by using only \tombi\ and refactors the CLI to return exit codes from the main function.

(repo-wide) · high confidence

Pixi now recognizes and manages a new \conda-script\ metadata block that can be embedded in source files of any language (such as C, C++, Go, Rust, Python, etc.) using a comment-based envelope. This allows users to define conda channels, dependencies, and entrypoints directly within their script files, enabling them to run scripts with \pixi run --experimental --script\ without needing a separate \pixi.toml\. The implementation includes parsing, validation, and editable document support for these blocks, along with language-specific templates for initializing new scripts.

_crates/pixi\manifest/src/script · high confidence

Users can now install only a specific subset of packages from the lock file using the \--only\ flag. This change introduces an \InstallSubset\ module that filters the dependency graph, allowing users to target specific packages while correctly handling their dependencies and skip rules.

_crates/pixi\_core/src/lock\file · high confidence

The \pixi\_spec\_containers\ crate now introduces a \DependencyMap\ structure that allows multiple requirements to be associated with a single package name. This change enables the system to handle scenarios where dependencies from multiple features are combined, preserving all distinct specifications for a given package rather than overwriting them. This foundational change supports the new capability of defining multiple dependencies within a single feature.

_crates/pixi\_spec\containers · high confidence

The workspace API now exposes functions to list, add, alias, and remove tasks across environments. The list function returns tasks grouped by environment along with runnability status derived from the lock file, while add and alias operations automatically declare required platforms if they are not yet present in the workspace manifest. Removal operations allow targeting specific platforms without auto-declaring new ones, ensuring precise control over task definitions.

_crates/pixi\api/src/workspace/task · high confidence

The \pixi publish\ command now supports publishing multiple packages from a single workspace in one operation. By setting \publish = true\ in the \\[package\]\ section of individual package manifests, users can trigger a workspace-wide publish that automatically discovers all opted-in packages, validates that they form a self-contained set (every source dependency must also opt in), and builds/uploads them in dependency order. This ensures that packages depending on other workspace packages are built after their dependencies, preventing missing-run-dependency errors on the target channel. If no packages opt in, the command falls back to publishing the single package at the current directory.

_crates/pixi\cli/src/publish · high confidence

The \src/cli\ module has removed the source files for the \add\, \init\, and \sync\ commands, along with their registration in the command dispatcher. This eliminates the previous implementation of these CLI interfaces, which relied on the older \Project\ and \CondaLock\ structures, effectively removing these capabilities from the command-line interface until replaced by new implementations.

src/cli · high confidence

The logic for comparing two lock files and identifying added, removed, or changed packages has been moved into a new, standalone \pixi\_diff\ crate. This refactoring isolates the diffing behavior, making the codebase more modular and allowing the diffing functionality to be reused or tested independently from the core lock file management logic.

_crates/pixi\diff · high confidence

The \pixi\_consts\ crate now centralizes project-wide constants, including default environment and feature names, manifest file names (\pixi.toml\, \pyproject.toml\, \mojoproject.toml\), cache directory paths, and CLI help section headers. It also defines the default configuration and lock file names, release URLs, and styling constants for console output (such as colors for tasks, platforms, and package types), along with emoji implementations for Conda and PyPI packages to improve CLI readability.

_crates/pixi\consts · high confidence

The core functionality of Pixi has been reorganized into a new, standalone \pixi\_core\ crate. This change introduces dedicated modules for environment activation, lock-file reporting with progress bars, shell prompt and hook generation (for Bash, Zsh, Fish, etc.), and cross-platform signal handling. It also includes a \RayonPrimer\ to manage thread-pool initialization and exposes key types like \Workspace\ and \InstallFilter\ for external use.

_crates/pixi\core/src · high confidence

The \pixi\_manifest\ crate has been reorganized from a single large source file into a modular structure with dedicated modules for activation, build systems, channels, dependencies, discovery, environments, features, and more. This refactoring improves code maintainability and separation of concerns within the manifest parsing and validation logic.

_crates/pixi\manifest/src · high confidence

The lock-file satisfiability logic has been split from a single monolithic module into dedicated submodules (environment, errors, platform, pypi, pypi\_metadata, source\_record) to improve maintainability. This refactoring preserves the existing public API and verification behavior, ensuring that lock-file validation for environments, platforms, PyPI packages, and source records continues to work as before while organizing the code for easier future development.

_crates/pixi\_core/src/lock\file/satisfiability · high confidence

The core logic for discovering, validating, and executing tasks has been extracted into a dedicated \pixi\_task\ crate. This change introduces structured error handling for scenarios such as missing, ambiguous, or unrunnable tasks (e.g., when a task is defined in an environment incompatible with the current platform), and implements a new file-hashing mechanism using xxh3 for accurate task caching. It also standardizes how command-line arguments are passed to the shell by joining them with single quotes to preserve backslashes and special characters correctly.

_crates/pixi\task · high confidence

Users can now open and use lock files created with versions prior to v7 without being forced to immediately re-lock. The system detects legacy lock files and lazily recomputes the missing build and host package environments for source records by querying the build backend. This process is optimized with an on-disk cache to avoid redundant computation, ensuring that existing workflows remain functional while the lock file format evolves.

_crates/pixi\_core/src/lock\file/satisfiability/legacy · high confidence

The CMake build backend has been rewritten to improve build reliability and caching precision. It now queries Ninja to determine the exact set of source files and headers that drove the build, replacing broad glob-based tracking; this ensures that changes to headers or CMakeLists.txt correctly trigger rebuilds. Additionally, the generated build scripts now properly quote paths containing spaces (such as install prefixes and Python interpreters) to prevent argument splitting errors on both Windows and Unix systems.

_crates/pixi\_build\cmake/src · high confidence

The conda-to-PyPI mapping logic has been refactored into a dedicated crate that supports project-defined, per-channel mappings. Users can now configure how specific channels map to PyPI packages by providing custom mapping sources (local files, remote URLs, or in-memory data) and selecting a mode for each channel: \Overlay\ (project entries win, falling back to the default prefix.dev mappings), \Replace\ (project entries completely override the defaults), or \Disabled\ (no PyPI mapping for that channel). This allows precise control over package resolution, such as overriding default mappings for non-conda-forge channels or disabling PyPI lookups entirely for specific sources.

_crates/pypi\mapping · high confidence

The pixi compute engine now manages cache directory paths and environment variable lookups as tracked dependencies within its dependency graph. Cache directories are resolved through a new \CacheDirs\ system that supports global and workspace anchors, programmatic overrides, and environment variable overrides (e.g., \PIXI\_GIT\_CACHE\_DIR\), ensuring that changes to these configurations are properly detected for caching purposes. Similarly, environment variables are now accessed via an \EnvVarsKey\ snapshot and individual \EnvVar\ keys, allowing the engine to track exactly which environment variables are read by each computation, improving cache invalidation accuracy.

_crates/pixi\_compute\_cache\_dirs, crates/pixi\_compute\_env\vars · high confidence

Pixi now detects when an environment directory has been moved and prompts the user to recreate it, preventing issues caused by non-relocatable environments. Additionally, the system now generates conda-meta files (prefix location and history) within the environment directory to ensure compatibility with external tools like \conda run\.

_crates/pixi\core/src/environment · high confidence

The command dispatcher now explicitly tracks and preserves the build platform for nested derived environments (such as build and host environments used during source solves). Previously, these nested environments might have inherited the target platform incorrectly; now, the \EnvironmentRef\ type carries a \DerivedPlatform\ that ensures build environments are solved on the build platform and host environments inherit the parent's platform. This change ensures that cross-compilation scenarios are handled correctly, preventing packages from being solved for the wrong architecture.

_crates/pixi\_command\dispatcher/src/environment · high confidence

The \pixi\glob\ module has replaced its previous \wax\-based implementation with the \ignore\ crate to handle glob pattern matching. This change introduces several behavioral adjustments: glob patterns are now rebased to a shared search root, allowing patterns like \../src/\.rs\ to work correctly even when starting from nested directories. The walker now follows symlinks to directories, ensuring that linked content is included in matches. Additionally, plain file names without meta-characters (e.g., \pixi.toml\) are anchored to the search root rather than matching anywhere in the tree, and negated patterns starting with \\\/\ are treated as global exclusions that are not rebased. Hidden files and directories are excluded by default unless explicitly opted in, and the implementation supports marker-driven workspace discovery for features like ROS package detection.

_crates/pixi\_glob/src/glob\set · high confidence

The \pixi remove\ command now prevents users from removing the Python package if the workspace still contains PyPI dependencies. Attempting to do so will fail with a clear error message listing the specific PyPI dependencies that must be removed first, ensuring dependency consistency before the lockfile is updated.

_crates/pixi\api/src/workspace/remove · high confidence

The \pixi\_toml\ crate has been refactored to use the \toml-span\ library for deserialization, which significantly enhances the user experience when configuration files contain errors. This change introduces richer diagnostic messages, including helpful suggestions like "Did you mean...?" for typos in keys or values, and clearer labels for unexpected or duplicate keys. Additionally, the new deserialization layer adds support for previously unsupported Rust collection types—such as \BTreeSet\, \IndexMap\, \IndexSet\, and \HashMap\—ensuring that order is preserved where expected and that complex configuration structures are parsed correctly.

_crates/pixi\toml · high confidence

When \pixi remove\ fails because a dependency is not found, the command now provides specific help text suggesting where the dependency might actually be located (e.g., in a different feature or dependency table) and offers spelling corrections for similar package names. This change replaces the previous generic error with actionable guidance to help users correct their commands.

_crates/pixi\cli/src/remove · high confidence

The pixi CLI now spawns its primary execution logic on a dedicated thread with a configurable stack size (defaulting to 4MB, or respecting the RUST\_MIN\_STACK environment variable if set). This change addresses stack overflow issues, particularly on Windows where the default stack size is significantly smaller, by ensuring the main thread has sufficient space for deep call stacks during CLI operations.

crates/pixi/src · high confidence

The \pixi\_record\ crate now uses canonical source specifications for equality comparison, meaning git sources are identified by their commit hash rather than branch or tag references, and Git LFS status is included in the identity. A new \DevSourceRecord\ type allows source packages to be resolved as virtual packages where only dependencies are installed. Lock file resolution has been refactored to use an index-based lookup with topological ordering, and source record identifiers now incorporate variant values and inline content hashes to ensure accurate rebuild detection.

_crates/pixi\record · high confidence

The \pixi\_command\_dispatcher\ now includes a dedicated module for executing source package builds via the build backend. This change introduces a new \BackendSourceBuildSpec\ and execution path that manages the build lifecycle, including passing channel configurations, dependencies, and variant data to the backend. Crucially, it adds concurrency limiting via a semaphore to prevent resource exhaustion during parallel builds, and integrates a reporter system to stream build logs and report progress to the user interface.

_crates/pixi\_command\_dispatcher/src/backend\_source\build · high confidence

The build subsystem now uses a command dispatcher architecture that explicitly models build and host environments (including platform and virtual packages) and resolves dependencies via a new protocol. This change adds support for pin-compatible and pin-subpackage dependency specs, allowing build dependencies to constrain run dependencies based on resolved versions, and introduces conversion logic to map backend source and binary specs into internal pixi specs.

_crates/pixi\_command\dispatcher/src/build · high confidence

The workspace search API now supports fuzzy matching for bare package names. When a user searches for a package name without specific version constraints, the system first attempts an exact match; if no results are found, it falls back to a 'contains' search across all available package names, ranking results by prefix matches. This allows users to use wildcard-like patterns (e.g., 'python\*') to discover related packages. The search respects a configurable limit on the number of fuzzy matches fetched to avoid excessive network requests, and returns channel notices alongside the results.

_crates/pixi\api/src/workspace/search · high confidence

The \pixi\_stable\_hash\ crate now includes utilities for generating consistent hashes of \serde\_json::Value\ and map-like iterables. The new \StableJson\ hasher ensures that JSON object key order does not affect the resulting hash (by default), while array order and type discriminants are preserved to prevent collisions. Additionally, \StableMap\ provides stable hashing for iterators over key-value pairs, incorporating entry counts and field discriminants. These additions support the broader refactor to extract stable hashing logic, ensuring that dependency and configuration changes trigger rebuilds only when the semantic content changes, not merely when serialization order varies.

_crates/pixi\_stable\hash · high confidence

The \pixi\_build\_frontend\ crate now includes a new \BackendError\ type that parses and structures JSON-RPC errors from build backends. This change enables users to receive richer error diagnostics, including severity levels, source code labels, and related error chains, rather than just plain text messages.

_crates/pixi\_build\frontend/src/error · high confidence

The \instantiate\_tool\_env\ module now defines the \InstantiateToolEnvironmentSpec\ struct, which captures the configuration required to create a cached tool environment, including package requirements, additional dependencies, constraints, build environment settings, channels, \exclude\_newer\ cutoffs, and variant configurations. It also provides the \InstantiateToolEnvironmentResult\ to return the resulting environment prefix, installed version, and Pixi build API version. The module introduces a comprehensive \InstantiateToolEnvironmentError\ enum to handle specific failure modes such as prefix creation, lock acquisition, solving, installation, and missing backend dependencies, ensuring users receive clear diagnostics when tool environment instantiation fails.

_crates/pixi\_command\_dispatcher/src/instantiate\_tool\env · high confidence

Adds a new module for managing build-backend metadata that integrates with the command dispatcher's compute engine. This change introduces a caching layer for backend metadata, keyed by manifest source, preferred build source, and environment context (including channels, variants, and exclude-newer settings). It ensures that metadata is correctly invalidated when the backend specification changes, preventing stale builds, and handles checkout roots for git and URL sources while warning about mutable environment backends that cannot be safely cached.

_crates/pixi\_command\_dispatcher/src/build\_backend\metadata · high confidence

The lock-file resolution process now initializes conda prefixes for PyPI source builds on demand rather than upfront. By introducing a \LazyBuildDispatch\ mechanism, the system avoids the heavy cost of preparing every environment prefix at the start, which significantly improves performance and stability when resolving across multiple platforms. Additionally, a custom \CondaResolverProvider\ now intercepts PyPI resolution requests for packages already provided by conda, overriding them with the locked conda versions to prevent conflicts and ensure consistent dependency resolution.

_crates/pixi\_core/src/lock\file/resolve · high confidence

The CLI source code has been refactored by consolidating the command modules into a single \src\ directory and introducing a new \pixi\_api\ abstraction for workspace interactions. This change introduces several new capabilities: the \pixi add\ command now supports adding local path dependencies via \--path\ and PyPI editable packages; the \pixi build\ command is deprecated in favor of \pixi publish\ (which now handles both building and uploading); and the \pixi clean\ command has been expanded to allow granular cleaning of specific cache types (e.g., pypi, conda, exec, build\_backends). Additionally, the completion system has been reworked to provide context-aware suggestions for environments, platforms, features, and tasks, and the \pixi config\ command now supports editing configuration files directly.

_crates/pixi\cli/src · high confidence

The Mojo build backend now automatically detects which subcommand is available in the installed Mojo compiler. If \mojo precompile\ is supported, it uses that command and produces \.mojoc\ output files; otherwise, it falls back to the legacy \mojo package\ command and produces \.mojopkg\ files. This ensures compatibility with both newer Mojo versions that renamed the packaging command and older versions that still use the original name.

_crates/pixi\_build\mojo/src · high confidence

The build frontend now uses a new JSON-RPC-based communication protocol to interact with build backends, replacing the previous mechanism. This change introduces a \JsonRpcBackend\ implementation that manages the lifecycle of backend processes, including spawning, capability negotiation, and method invocation via JSON-RPC. It also adds robust error handling for common failure modes such as missing executables, premature exits, and protocol mismatches. Additionally, the system now streams backend stderr output in real-time, allowing users to see build logs as they happen, while buffering the output for potential error reporting if the backend fails unexpectedly.

_crates/pixi\_build\frontend/src/backend · high confidence

A new \plan\ module has been introduced in \crates/pixi\_install\_pypi\ to manage the installation of Python packages into Conda environments. This module introduces \InstallPlanner\ to coordinate installation actions, \DistCache\ traits to resolve whether packages can be served from local cache or must be fetched remotely, and \InstallationSources\ to categorize distributions by their source. It also defines \PyPIInstallationPlan\ and \NeedReinstall\ to track reinstalls based on specific reasons such as version mismatches, source mismatches (e.g., registry vs. direct URL), and Git LFS state changes. This refactoring extracts and structures the core logic for determining installation sources and validating current installations against locked requirements.

_crates/pixi\_install\pypi/src/plan · high confidence

The manifest parser has been rewritten to use \toml\_span\ for deserializing \pixi.toml\ and \pyproject.toml\ files. This change introduces new modules for parsing build backends, channels, environments, features, and workspace dependencies, enabling more robust error reporting and formatting preservation. It also adds support for new configuration fields such as \conda-pypi-map\, \solve-strategy\, and \exclude-newer\, while deprecating legacy fields like \configuration\ in favor of \config\.

_crates/pixi\manifest/src/toml · high confidence

The \crates/pixi\_pypi\_spec\ crate introduces a dedicated module for handling PyPI dependency specifications, replacing the previous ad-hoc parsing logic. It defines the \PixiPypiSpec\ and \PixiPypiSource\ types to model dependencies from registries, Git repositories, local paths, and URLs, supporting PEP 508 environment markers and extras. The crate includes robust TOML deserialization with improved error messages for invalid configurations (such as conflicting version specifiers or missing \git\ keys) and implements conversion from \pep508\_rs::Requirement\ to handle standard PEP 508 strings, including file URLs and git URLs with subdirectories.

_crates/pixi\_pypi\spec · high confidence

Pixi now uses a new command dispatcher built on the \pixi\_compute\_engine\ to manage builds, solves, and environment instantiation. This change introduces content-addressed caching for build backends, ephemeral environments, and input snapshots, ensuring that builds are only re-run when their actual inputs (source files, configuration, or backend specs) change. It also adds support for inline package definitions, allowing build manifests to be specified directly in the workspace rather than on disk, and improves error reporting with detailed diagnostics for issues like platform mismatches in build environments.

_crates/pixi\_command\dispatcher/src · high confidence

Pixi now uses a new content-addressed cache for source builds, located under \.pixi/artifacts-v0/\ (or the global cache root). This cache stores built \.conda\ artifacts keyed by a hash of all build inputs (source, dependencies, platform, backend, and overrides), allowing Pixi to skip the entire build process when a cached artifact is found. The cache distinguishes between mutable sources (like local paths) and immutable sources (like git commits or URL archives), tracking file freshness via mtimes and content hashes for mutable sources to avoid unnecessary rebuilds while ensuring correctness. A separate backend metadata cache avoids re-invoking build backends for unchanged sources, and a workspace cache preserves incremental build state (e.g., CMake/ninja state) keyed on the full dependency set to handle prefix-sensitive builds correctly.

_crates/pixi\_command\dispatcher/src/cache · high confidence

The \pixi install\ command now uses a new command dispatcher implementation located in \crates/pixi\_command\_dispatcher/src/install\_pixi\. This change introduces concurrent source-package building via \SourceBuildKey\, allowing source records to be built in parallel before the binary packages are installed. It also adds support for inline package definitions, enabling source packages to be built from in-memory manifests rather than requiring disk discovery. The installation process now includes a dedicated reporter lifecycle for progress tracking and handles source-build cache clearing on force-reinstall. Additionally, the dispatcher ensures that source packages are always built in development mode and uses the fastest compression format for intermediate artifacts.

_crates/pixi\_command\_dispatcher/src/install\pixi · high confidence

A new \pixi\_uv\_conversions\ crate has been introduced to centralize the translation between Pixi's internal manifest types and the \uv\ ecosystem. This change adds specific logic to scope PyPI source-build caches by conda environment fingerprint and macOS deployment target, ensuring build artifacts are not incorrectly reused across different environments. It also introduces robust handling for Git URLs, including support for the \git+\ prefix, Windows drive-letter encoding in \file://\ URLs, and the new \lfs\ field for Git dependencies. Additionally, the crate provides utilities to convert PyPI options (such as \no-binary\, \no-build\, and index locations) into \uv\ build configurations and manages workspace-relative path anchoring for lockfile stability.

_crates/pixi\_uv\conversions · high confidence

The \pixi\_compute\_sources\ crate now provides the core logic for resolving and checking out package sources (Git, URL, and local paths) within the compute engine. A key behavioral change is the addition of an \lfs\ field to Git dependencies: when \lfs = true\ is specified, the checkout process fetches Git LFS objects to provide real file content instead of pointer files, and this preference is recorded in the pinned spec. The system also introduces distinct cache directories and concurrency semaphores for Git and URL checkouts, and fixes a deduplication bug in \CheckoutGit\ by including the \precise\ commit hash in the cache key to prevent accidental reuse of branch HEADs when a specific commit was requested.

_crates/pixi\_compute\sources · high confidence

The pixi\_allocator crate now configures global memory allocators to improve performance on supported platforms. On Windows, it uses mimalloc, while on Linux, macOS, and other supported architectures (x86\_64, aarch64, powerpc64), it switches to tikv\_jemallocator. This change is applied conditionally to avoid the long compilation times associated with these allocators on unsupported platforms.

_crates/pixi\allocator · high confidence

The \pixi\_build\_types\ crate introduces protocol version 7, which adds \pin-subpackage\ and \pin-compatible\ dependency specifications to the project model and run-export tables, and includes \run\_exports\ in the project model targets. This version also enforces structured serialization of match specs in the \conda/build\_v1\ API, introduces extra dependency groups, and supports \if(\<expression\>)\ target selectors passed through to rattler-build. The API version is now constrained to 7, and the crate exposes types for backend/frontend capabilities, channel configuration, conda package metadata, validated extra group names, and structured input glob sets to support these protocol features.

_crates/pixi\_build\types/src · high confidence

The pixi-build-backends packages (cmake, mojo, python, r, rattler-build, ros, and rust) have been updated to require pixi-build-api-version \>=7,\<8. This change ensures compatibility with the latest build API contract and aligns the backend binaries with the current pixi build system expectations.

pixi-build-backends · high confidence

When installing PyPI packages from the lock file, pixi now verifies the integrity of registry artifacts (wheels and source distributions) against the digests recorded in the lock file, failing the install if a mismatch is detected. Additionally, source builds are now cached per conda environment to prevent cache collisions, while ensuring that environment-specific build settings do not leak into the PEP 517 backend configuration.

_crates/pixi\_install\pypi/src · high confidence

The pixi-build-python backend now uses uv as the default installer for building and installing Python wheels, falling back to pip only if explicitly configured, which improves build speed and consistency. Users can now configure PyPI-to-conda package name mappings (including dropping dependencies) via the \pypi-conda-map\ setting, enable Python Stable ABI (abi3) builds for compiled extensions, and skip .pyc compilation for specific file patterns. The backend also tracks Cython source inputs for editable builds and points the uv cache to the pixi cache directory to avoid redundant downloads.

_crates/pixi\_build\python/src · high confidence

The manifest layer for PyPI options has been refactored to use a new union-style merge policy, introducing specific merge behaviors for single options (conflict detection), lists (deduplication), and maps (left-override). This change also adds validation to prevent conflicting configurations, such as specifying multiple primary indexes, multiple index strategies, or incompatible pre-release modes, ensuring that merged \pypi-options\ from different scopes (e.g., workspace and package) are consistent and valid.

_crates/pixi\manifest/src/pypi · high confidence

The \src\ directory has removed the legacy project scaffolding and implementation files, including \config.rs\, \consts.rs\, \main.rs\, \progress.rs\, \project.rs\, and \repodata.rs\. This deletes the previous project manifest handling (previously using \pax.toml\), the custom progress bar UI implementation, and the direct repodata fetching logic, indicating a structural shift in how the application manages project state and interacts with package repositories.

src · high confidence

The \pixi global\ command interface has been restructured to support a more granular and robust workflow. A new \pixi global add\ command allows adding dependencies to existing environments, while \pixi global expose\ provides explicit subcommands (\add\/\remove\) for managing executable mappings. The \pixi global edit\ command now opens the global manifest in your preferred editor. Error handling has been significantly improved: operations like \install\, \add\, and \remove\ now automatically revert environment changes if they fail, and \pixi global sync\ runs installations in parallel while providing a progress spinner for better feedback. Additionally, \pixi global list\ now supports JSON output via \--json\, and \pixi global tree\ allows visualizing dependency trees for specific environments.

_crates/pixi\cli/src/global · high confidence

The \pixi-build-ros\ backend has been rewritten in Rust, replacing the previous Python implementation. This change introduces a new build script template system that selects and renders platform-specific scripts for \ament\_cmake\, \ament\_python\, \cmake\, and \catkin\ build types. The backend now includes native parsing of ROS \package.xml\ manifests, automatic ROS distribution detection from RoboStack channels, and workspace discovery logic that identifies sibling ROS packages to resolve dependencies locally. It also handles package mapping between ROS and conda names, supports custom package mapping sources, and manages ROS version mutex packages to ensure build consistency.

_crates/pixi\_build\ros/src · high confidence

The Rust build backend has been refactored to use a new \build\_script.rs\ and \build\_script.j2\ module that generates the build script dynamically. This change introduces explicit configuration for the \compilers\ field (defaulting to \rust\ and \c\) and a new \binaries\ field that allows users to select specific cargo binaries to install. The generated script now explicitly sets \CARGO\, \RUSTC\, and \RUSTDOC\ environment variables to paths within the build prefix, and handles platform-specific syntax for bash and cmd.exe. Additionally, the backend now supports \sccache\ integration via the \has\_sccache\ flag and properly handles \OPENSSL\_DIR\ for host environment detection. The \RustBackendConfig\ has been updated to support these new fields, and the \CargoMetadataProvider\ now includes logic to handle virtual workspaces with helpful error messages.

_crates/pixi\_build\rust/src · high confidence

The Rust build backend now automatically includes the C compiler (\compiler('c')\) in the build requirements alongside the Rust compiler, ensuring that packages depending on C extensions can be built without manual configuration. Additionally, when sccache is enabled, it is now explicitly added to the build requirements, and its configuration (such as bucket and secrets) is correctly propagated into the build script environment. These changes ensure that generated recipes for Rust packages are more robust and ready for complex builds out of the box.

_crates/pixi\_build\rust/src/snapshots · high confidence

The manifest parser now enforces stricter validation rules across several areas. For build backends, the \configuration\ field is deprecated in favor of \config\, and the \\[build-system\]\ section is now gated behind the \pixi-build\ preview flag. Environment definitions now require the \features\ field, and invalid keys like \feat\ or \solve\_groups\ are rejected. Dependency handling has been tightened: \workspace = true\ entries can no longer restate a version, and \pixi-build\ mode restricts \build-dependencies\ and \host-dependencies\ to the package scope. Additionally, the \conda-pypi-map\ configuration now rejects unsupported values like \true\ or empty tables, and platform selectors must match declared workspace platforms.

_crates/pixi\manifest/src/toml/snapshots · high confidence

The manifest editing layer has been refactored to use a single \ManifestDocument\ enum that wraps all supported manifest formats (pixi.toml, pyproject.toml, MojoProject.toml, PEP 723 scripts, and conda-script files). This change centralizes parsing, rendering, and provenance tracking, ensuring that edits preserve formatting and comments consistently across all manifest types while correctly handling symlinked paths and script-specific metadata blocks.

_crates/pixi\manifest/src/manifests · high confidence

The pixi compute reporters now provide a shared infrastructure for consistent reporting across different compute sources. This introduces \OperationId\ and \OperationRegistry\ to assign stable, hierarchical IDs to reporter events, allowing callbacks to understand parent-child relationships between tasks. Additionally, a \ReporterLifecycle\ typestate automates the \on\_queued\ → \on\_started\ → \on\_finished\ sequence, ensuring \on\_finished\ fires reliably when a reporter context is dropped.

_crates/pixi\_compute\reporters · high confidence

The manifest parser now supports inheriting package dependencies from a central \\[workspace.dependencies\]\ section, allowing you to define a dependency once in the workspace and reference it in packages using \workspace = true\. This change also introduces stricter validation for dependency tables: duplicate package names are now rejected with clear error messages, and \pin-subpackage\ or \pin-compatible\ specs are correctly restricted to package-level tables. Additionally, source dependencies (like Git or path sources) are now gated behind the \pixi-build\ preview flag, providing specific guidance on how to enable it if encountered.

_crates/pixi\manifest/src/utils · high confidence

Pixi now provides detailed, actionable error messages when an environment cannot run on the current machine, explaining exactly which declared platform fails and why (e.g., missing virtual packages or incompatible subdirs), and includes hints for mocking capabilities or using \--platform\. Additionally, the \conda-pypi-map\ configuration is validated to ensure every mapped channel is actually declared in the workspace or feature channels, preventing silent misconfigurations from typos.

_crates/pixi\core/src/workspace · high confidence

The Windows installer (Wix) has been updated to install pixi in the user's local app data directory (per-user scope) rather than the system-wide Program Files, and the installation now includes the project's BSD 3-Clause license file as a sidecar.

crates/pixi/wix · high confidence

Add test fixtures for build backends and package channels; Added ROS workspace test fixtures for distro-less and multi-language packages; Added import and version verification tests for PyPI source dependency example; Added integration test snapshots for command dispatcher scenarios; Added integration test snapshots for dependency management and search features; Added integration tests for the pixi build backend protocol; Added mock PyPI package fixtures for rebuild testing; Added schema validation tests for pixi.toml and pyproject.toml manifests; Added snapshot tests for build backend discovery; Added snapshot tests for pixi build frontend conversions; Added solve-groups example with environment isolation tests; Added test fixture for editable Python package detection; Added test fixtures for local library sources; Added test fixtures for minimal PyPI package versions; Added test fixtures for multi-package PyPI git dependencies; Added test fixtures for multiple PyPI index scenarios; Added test fixtures for pixi-build scenarios; Added test fixtures for run-exports conditional logic; Added test fixtures for v6 editable and local archive scenarios; Added tests for URL source caching and validation; Added tests for build backend discovery logic; Added tests for conda-to-PyPI mapping logic in the conda\_mapping example; Added tests for the PyPI install planner; Added version verification test for the Polarify example; Integration test suite for the command dispatcher; New Rust integration test suite for pixi core workflows; New integration test infrastructure for Pixi CLI commands; New test utilities for git fixtures and mock repository data; Snapshot tests for pixi-build type conversions now include conditional dependencies, extras, and dev dependencies; Updated conda environment and explicit spec export snapshots; Updated conda environment file import test snapshots; Updated glob hash test snapshots; Updated lock-file satisfiability test snapshots; Updated manifest snapshot tests for environment, activation, and dependency management; Updated workspace discovery and system requirements test snapshots.

The repository has been reorganized into a larger workspace, adding numerous new crates that were previously part of the monolithic \pixi\ crate. This includes \pixi\build\\*\ crates (e.g., \pixi\_build\_python\, \pixi\_build\_cmake\, \pixi\_build\_ros\) to handle specific build backends, \pixi\_config\ for global configuration, and \pixi\compute\\*\ crates (e.g., \pixi\_compute\_engine\, \pixi\_compute\_network\) for incremental computation and caching. New utility crates like \barrier\_cell\, \fancy\_display\, and \pixi\_allocator\ (with platform-specific allocators like \tikv-jemallocator\ and \mimalloc\) have also been added. These changes reflect a structural refactor to improve modularity and separation of concerns within the Pixi codebase.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 72 → 58 (-13.5)
• Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.

• Code Health 85 → 91 (+6.5)
• Architecture 67 → 47 (-20.1)
• Maturity 75 → 75 (-0.0)
• Readiness 70 → 65 (-4.7)
• Security 80 → 80 (+0.7)
• Domain Modelling 100 → 100 (+0.0)
• Event Sourcing 100 → 100 (+0.0)
• Performance 60 (new)

• Duplicated block (15 lines × 5) (crates/pixi_api/src/workspace/workspace/platform.rs)
• Duplicated block (8 lines × 2) (crates/pixi_config/src/lib.rs)
• Edited copy of a member (24 corresponding lines) (crates/pixi_cli/src/config.rs)
• Further sole-owners (lower concentration)
• High CVE: [GHSA redacted] (Cargo.lock)
• Hotspot: crates/pixi_api/src/workspace/list/package.rs (crates/pixi_api/src/workspace/list/package.rs)
• Hotspot: crates/pixi_cli/src/list.rs (crates/pixi_cli/src/list.rs)
• Hotspot: crates/pixi_cli/src/tree.rs (crates/pixi_cli/src/tree.rs)
• Hotspot: crates/pixi_cli/src/workspace/activation.rs (crates/pixi_cli/src/workspace/activation.rs)
• Hotspot: crates/pixi_git/src/git.rs (crates/pixi_git/src/git.rs)
• Hotspot: crates/pixi_global/src/common.rs (crates/pixi_global/src/common.rs)
• Hotspot: crates/pixi_install_pypi/src/lib.rs (crates/pixi_install_pypi/src/lib.rs)
• Hotspot: crates/pixi_install_pypi/src/plan/validation.rs (crates/pixi_install_pypi/src/plan/validation.rs)
• Hotspot: crates/pixi_spec/src/toml.rs (crates/pixi_spec/src/toml.rs)
• Members sharing a duplicated core (5 members, 50+ identical tokens) (crates/pixi_api/src/workspace/workspace/platform.rs)
• Off-boarding risk: anonymized user #1
• Off-boarding risk: anonymized user #2
• Off-boarding risk: anonymized user #3
• Off-boarding risk: anonymized user #4
• Repeated repair: crates/pixi_api/src/workspace/list/mod.rs (crates/pixi_api/src/workspace/list/mod.rs)
• …and 3 more

• Documentation: no project overview (examples/wasm-jupyterlite/README.md)
• Duplicate search method with inconsistent signatures. One variant accepts a Config parameter, while the other does not. It is unclear if the Config parameter is optional, required, or if one is deprecated.
• Duplicated block (10 lines × 2) (examples/rerun_example/nuscenes_dataset/nuscenes_dataset/main.py)
• Duplicated block (11 lines × 2) (examples/rerun_example/lidar/lidar/download_dataset.py)
• Duplicated block (11 lines × 2) (scripts/local_patch.py)
• Duplicated block (12 lines × 2) (crates/pixi_api/src/workspace/workspace/platform.rs)
• Duplicated block (13 lines × 2) (examples/rerun_example/lidar/lidar/download_dataset.py)
• Duplicated block (15 lines × 2) (scripts/local_patch.py)
• Duplicated block (16 lines × 2) (crates/pixi_cli/src/update.rs)
• Duplicated block (16–18 lines × 2) (examples/rerun_example/lidar/lidar/main.py)
• Duplicated block (17 lines × 2) (docs/source_files/pixi_workspaces/pixi_build/getting_started/src/python_rich/init.py)
• Duplicated block (18 lines × 2) (docs/source_files/pixi_workspaces/pixi_build/workspace/src/python_rich/init.py)
• Duplicated block (22 lines × 2) (examples/rerun_example/lidar/lidar/main.py)
• Duplicated block (26 lines × 2) (examples/turtlesim/turtle_marker_viz_ROS1.py)
• Duplicated block (5 lines × 2) (scripts/create_release.py)
• Duplicated block (5 lines × 2) (trampoline/build-trampoline.py)
• Duplicated block (5–6 lines × 2) (crates/pixi_cli/src/config.rs)
• Duplicated block (9 lines × 2) (examples/rerun_example/lidar/lidar/download_dataset.py)
• Edited copy of a member (24 corresponding lines) (crates/pixi_cli/src/config.rs)
• End-of-life runtime: Rust 1.95
• …and 50 more

• 40 commits — 27 feature/other, 13 fixes

• (root) — 11 commits
• .github/workflows — 8 commits
• crates/pixi_command_dispatcher — 4 commits
• crates/pixi_cli — 2 commits
• crates/pixi_core — 2 commits
• docs/build — 2 commits
• tests/data — 2 commits
• .github/actionlint.yml — 1 commit
• crates/pixi_api — 1 commit
• crates/pixi_build_ros — 1 commit
• crates/pixi_config — 1 commit
• crates/pixi_task — 1 commit
• crates/pixi_utils — 1 commit
• docs/reference — 1 commit
• docs/source_files — 1 commit
• docs/tutorials — 1 commit

• fix: fix(deps): bump quinn-proto to 0.11.15 (#7103)
• fix: fix(dispatcher): add PrefixPlatformMismatchError for source build prefixes (#6984)
• fix: fix(dispatcher): keep nested derived environments on the build platform (#6986)
• fix: fix(docs): pin mojo version to 1.0.0 in conda-script example (#7048)
• fix: fix: CLI arg --clean-env is no longer ignored (#7096)
• fix: fix: accept custom per-package index in satisfiability for unindexed requirements (#7024)
• fix: fix: allow removing current platform in pixi workspace platform remove (#7026)
• fix: fix: concurrency config set correctly targets concurrency config (#6991)
• fix: fix: pass stored credentials to the OCI middleware (#7014)
• fix: fix: preserve error chain and diagnostics on build dispatch failure (#7028)
• fix: fix: preserve quotes in task arguments (#7091)
• fix: fix: sort source record dependencies and constraints for lockfile determinism (#7011)
• fix: fix: update git dependencies sharing same repository and reference together (#7023)
• change: chore(ci): Update GitHub Actions (#7078)
• change: chore(ci): Update GitHub Actions (#7113)
• change: chore(ci): Update Rust crate clap_complete to v4.6.11 (#7083)
• change: chore(ci): Update Rust crate dirs to v7 (#7006)
• change: chore(ci): Update Rust crate lzma-rust2 to 0.21 (#7114)
• change: chore(ci): Update Rust crate rstest to 0.27.0 (#7001)
• change: chore(ci): Update Rust crate serde_with to v3.23.0 (#7002)
• …and 20 more

• Containers 0 added · 0 removed · contexts 1 added · 0 removed · edges 0 added · 0 removed

• python

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

prefix-dev/pixi was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.