pixi-project
Manage and run pixi projects
TLDR
Manage project channels
Manage project description
Manage project platform
Manage project version
Manage project environment
SYNOPSIS
pixi project SUBCOMMAND [OPTIONS]
Common Subcommands:
pixi project add DEPENDENCY...
pixi project run SCRIPT_NAME [ARGS]...
pixi project install
pixi project shell
PARAMETERS
--manifest-path
Specifies the path to the pixi.toml manifest file, if not in the current directory.
--frozen
Prevents pixi.lock from being updated. Fails if the lock file is out of sync with pixi.toml.
--locked
Ensures pixi.lock is up-to-date with pixi.toml. Fails if it's out of sync without updating it.
--verbose
Increases the verbosity of the output, showing more detailed information.
--quiet
Decreases the verbosity of the output, showing less information.
add
A subcommand to add one or more dependencies to the project, updating pixi.toml and pixi.lock.
run
A subcommand to execute a custom script or command defined within the pixi.toml file, within the project's environment.
install
A subcommand to install all dependencies specified in pixi.lock into the project's isolated environment.
shell
A subcommand to open a new shell with the project's environment activated, making project-specific tools and dependencies available.
update
A subcommand to update all project dependencies to their latest compatible versions and regenerate pixi.lock.
remove
A subcommand to remove specified dependencies from the project, updating pixi.toml and pixi.lock.
info
A subcommand to display comprehensive information about the current project and its environment.
DESCRIPTION
The pixi project command group is a central component of the pixi package manager, not a standalone executable. It provides a comprehensive suite of subcommands for managing all aspects of a software project's lifecycle, from initialization and dependency management to script execution and environment setup.
It orchestrates a project's dependencies, ensuring a reproducible and isolated environment across different machines and collaborators. pixi project leverages the pixi.toml manifest file to define project metadata, dependencies (for various languages like Python, Rust, etc.), and custom scripts, while the pixi.lock file guarantees exact dependency versions for consistent builds. This command group streamlines common development workflows, making it easier to manage complex, polyglot projects and integrate with underlying package managers like Conda.
CAVEATS
The pixi project command group requires the pixi package manager to be installed. It operates on a project defined by a pixi.toml file, typically located in the current working directory or specified via --manifest-path. While powerful, pixi is a relatively new tool compared to established package managers, and its ecosystem and feature set are still evolving. Its underlying dependency resolution often relies on conda infrastructure, which might introduce specific behaviors or dependencies.
THE <I>PIXI.TOML</I> MANIFEST FILE
This TOML file is the central configuration for a pixi project. It defines project metadata, specifies direct dependencies, lists development dependencies, and can include custom scripts or tasks. It's the primary way to declare your project's requirements and behavior.
THE <I>PIXI.LOCK</I> LOCK FILE
Generated automatically by pixi based on pixi.toml, this file precisely pins the versions of all direct and transitive dependencies. It ensures that everyone working on the project, or deploying it, gets the exact same environment, guaranteeing reproducibility and preventing 'works on my machine' issues.
HISTORY
Pixi emerged from the prefix.dev initiative, driven by the need for a modern, unified package manager that can handle polyglot projects across multiple operating systems. It was conceived to address the fragmentation in dependency management for environments combining languages like Python, Rust, JavaScript, and more, building upon lessons learned from tools like conda and rye.
The project subcommand group has been fundamental to pixi's design from its early stages, providing the core interface for users to interact with their project's dependencies and environments. Its development reflects a focus on reproducibility, ease of use, and integration with existing package ecosystems.