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.
1.4 KiB
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 for details.
Self-hosted administrators must explicitly allow this path by including pixi in the global 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:
- renovatebot setting
constraints.pixi requires-pixiinpixi.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.