mirror of
https://github.com/renovatebot/renovate.git
synced 2026-11-01 02:00:10 +00:00
Niels Pardon
c3c70b8cdb
* feat(managers/pep621): update pixi.lock if present
* test(managers/pep621): cover pixi requires-pixi from workspace table
* refactor(manager/pixi): extract shared pixi.lock update helper
* test(manager/pep621): use arrange-act-assert spacing in pixi tests
* refactor(manager/pixi): revert shared pixi.lock helper extraction
Move the extraction of the shared pixi.lock update helper into a
follow-up PR, as requested in review. The pep621 pixi processor and the
pixi manager again carry their own lock-update logic.
This reverts commit 743db204f2.
* feat(manager/pep621): gate pixi.lock updates behind allowedUnsafeExecutions
`pixi lock` can execute arbitrary code from conda package hooks, so the
pep621 manager now only updates `pixi.lock` when `pixi` is included in the
global `allowedUnsafeExecutions` option, following the same pattern as the
`mise` manager. When `pixi` is not allowed, PEP 621 dependencies in
`pyproject.toml` are still updated but `pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
* feat(manager/pixi)!: gate pixi.lock updates behind allowedUnsafeExecutions
The pixi manager runs `pixi lock`, which can execute arbitrary code from
conda package hooks. Like the pep621 manager, it now only updates
`pixi.lock` when `pixi` is included in the global `allowedUnsafeExecutions`
option. When it is not allowed, the package file is still updated but
`pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
BREAKING CHANGE: The `pixi` manager no longer updates `pixi.lock`
automatically. To keep `pixi.lock` updated, add `pixi` to the global
`allowedUnsafeExecutions` option.
24 lines
1.4 KiB
Markdown
24 lines
1.4 KiB
Markdown
### Pixi package manager
|
|
|
|
Currently support channels from anaconda and prefix.dev, other channels are not supported yet.
|
|
|
|
Whenever the pixi config in `pyproject.toml` or `pixi.toml` file is updated, `pixi.lock` file will be checked for updates as well.
|
|
|
|
When using `pyproject.toml`, standard PEP 621 dependencies (e.g. `[project.dependencies]` or `[dependency-groups]`) are handled by the `pep621` manager, which also updates `pixi.lock` when those dependencies change.
|
|
|
|
### Trust model for pixi lock file updates
|
|
|
|
Running `pixi lock` can execute arbitrary code from conda package hooks, so Renovate treats `pixi.lock` refreshes as an unsafe execution.
|
|
See [pixi's security documentation](https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution) for details.
|
|
|
|
Self-hosted administrators must explicitly allow this path by including `pixi` in the global [`allowedUnsafeExecutions`](../../../self-hosted-configuration.md#allowedunsafeexecutions) setting.
|
|
When `pixi` is not allowed, the package file is still updated, but `pixi.lock` is left unchanged.
|
|
|
|
Renovatebot will pick pixi version in following order:
|
|
|
|
1. renovatebot setting `constraints.pixi`
|
|
2. `requires-pixi` in `pixi.toml`
|
|
|
|
The minimal support version of pixi is `0.40.0` (`pixi lock` has only been introduced with that version).
|
|
Therefore when you are setting `constraints.pixi` in your renovatebot config or `requires-pixi` in `pixi.toml`, please be careful to pick a supported pixi version.
|