feat: add more variables to task context #4949
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a `platform` variable to the MiniJinja context when rendering task
commands. This variable contains the best platform for the environment
in which the task will run (e.g., linux-64, osx-arm64, win-64).
This enables users to create platform-specific tasks without hardcoding
platform names:
```toml
[tasks]
build = { cmd = "cargo build --target {{ platform }}", args = [] }
download-binary = {
cmd = "curl -O https://example.com/binary-{{ platform }}.tar.gz",
args = []
}
```
The platform is automatically determined from the environment's
best_platform() method, which respects the environment configuration
and handles platform fallback (e.g., osx-64 on Apple Silicon when
osx-arm64 is not available).
Changes:
- Add platform parameter to TemplateString::render() and related methods
- Pass environment's best_platform() from ExecutableTask to render calls
- Add tests for platform variable rendering
- Update documentation with platform variable usage examples
Replace separate args and platform parameters with a unified
`TaskRenderContext` struct for passing rendering context. This makes
the API cleaner and more extensible for future system variables.
Key changes:
- `TaskRenderContext` now contains:
- `platform: Platform` (non-optional, defaults to Platform::current())
- `args: Option<&ArgValues>` (the task arguments)
- Add `with_args(platform, args)` constructor
- Create `pixi` object in Jinja context with system variables
- Access platform via `{{ pixi.platform }}` to avoid clashes with args
- Update all render methods to only take `&TaskRenderContext`
Usage example:
```rust
let context = TaskRenderContext::with_args(
env.best_platform(),
Some(&args)
);
task.as_single_command(&context)?;
```
Task template example:
```toml
[tasks]
build = { cmd = "cargo build --target {{ pixi.platform }}", args = [] }
```
This design allows easy addition of new system variables to the pixi
object without changing method signatures throughout the codebase.
Change platform variable access from {{ platform }} to {{ pixi.platform }}
to avoid potential clashes with user-defined task arguments. Also fixes
unused import warning and applies code formatting.
Update render_args and from_dependency methods to accept TaskRenderContext instead of args directly, ensuring consistent platform handling throughout the dependency rendering pipeline.
Extract MiniJinja context building into a dedicated method on TaskRenderContext. The context now always includes pixi system variables (like pixi.platform), even when no typed args are provided.
Update test code in pixi_core and pixi crates to use the new TaskRenderContext API instead of passing None directly.
Contributor
|
I like this, I would love to extend this with more variables. Here are some ideas: |
Contributor
|
This seems like a really nice addition! <3 |
Add new system variables available in task templates under the pixi namespace: - pixi.environment - The name of the current environment - pixi.manifest-path - Absolute path to the manifest file - pixi.version - The version of pixi - pixi.is_win, pixi.is_unix, pixi.is_linux, pixi.is_osx - Platform detection booleans Note: The platform detection booleans are accessible as pixi.is_win, etc. rather than pixi.platform.is_win to avoid minijinja type complexity. Updated TaskRenderContext to optionally include environment name and manifest path.
Contributor
Author
|
@ruben-arts I added those! Although I changed |
Update the documentation to include all available pixi template variables in a clear markdown table format. Added examples showing how to use: - Platform detection booleans for conditional logic - Environment-aware tasks - Manifest path access with bracket notation
Change pixi.manifest-path to pixi.manifest_path to avoid issues with dashes being interpreted as minus signs in MiniJinja. This is consistent with the variable naming convention and avoids the need for bracket notation.
Contributor
Author
|
Instead of |
- Changed manifest_path from Option<&Path> to Option<PathBuf> to avoid lifetime issues - Added render_context() method to ExecutableTask for consistent context construction - Removed new() and with_args() methods, using struct initialization syntax instead - Ensures environment name and manifest path are properly passed in all contexts - All tests passing
…ject - Changed manifest_path back to Option<&'a Path> to properly use lifetimes - Made environment_name required (non-optional) with &'a EnvironmentName - Changed pixi.environment to pixi.environment.name (environment is now an object) - Updated TaskNode::full_command to accept &TaskRenderContext parameter - Use TaskRenderContext::default() where appropriate with spread syntax - Removed command rendering from TaskNode Display impl - All tests passing
ruben-arts
approved these changes
Nov 21, 2025
Contributor
ruben-arts
left a comment
There was a problem hiding this comment.
I think this is a great addition! Thanks @baszalmstra and claude'tje
Contributor
|
Neat! Opened #5078 to update the schema to reflect the new reserved name. |
bollwyvl
added a commit
to bollwyvl/pixi
that referenced
this pull request
Dec 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adds a
pixi.platformvariable to the MiniJinja task context, allowing users to reference the current platform in their task commands.This is useful for creating platform-specific tasks without needing to define separate tasks for each platform:
The platform is accessed via the
pixinamespace (pixi.platform) to avoid potential clashes with user-defined task arguments.Closes #4940
Implementation details:
TaskRenderContextstruct to manage rendering context (platform and args)environment.best_platform()to determine the platform, which respects environment-specific platform settingsDiscussion
I suppose we want more useful variables in
pixi.likeis_win,os, orarch. I can add these if thats convenient?How Has This Been Tested?
crates/pixi_manifest/src/task.rs:test_template_string_renders_platform_variable- verifies platform renders correctlytest_template_string_renders_platform_with_args- verifies platform works alongside user argumentsAI Disclosure
Tools: Claude Code (Claude Sonnet 4.5)
Checklist:
schema/model.py.