Open abkfenris opened 1 month ago
This was done by design because users want to update the lock file through this for platforms they're not running on.
That said I see the issue you experience. I could see a few options:
pixi solve
or pixi lock
... . Then removing this behavior from pixi install
. pixi install
interactive with the dialog if you meant to just solve as there is no platform available for the current machine. Which automatically fails in non interactive shells. That makes sense.
I think an interactive dialog could be the best experience, especially if one of the prompts could be 'add this platform and solve/install'.
pixi install
WARN Not installing dependency on current platform: (osx-arm64) as it is not part of this project's supported platforms.
- Solve only for existing platforms [list of platforms]
-> Add this platform and install
- Exit with error
The wording could use some work, but that's what I've got before running out the door and heading out of service for a week or so.
I think erroring only in CI is more surprising, and leads down the path of 'what is CI', and makes things harder to debug.
I've also seen other conversations (at least #1131 ) that makes me think a pixi solve/lock
command would be also appreciated, and maybe useful for workflows where they are locking on CI for other platforms.
The "Do you want me to add the platform" dialog is something that was also on my mind. So this could possibly solve multiple issues.
Checks
[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of pixi, using
pixi --version
.Reproducible example
Issue description
When pixi install is called, but the current platform isn't included in the platforms list, it emits a warning, but it doesn't exit non-0, so it can be hard to catch with automated system (such as Docker builds).
Expected behavior
I would expect
pixi install
and similar commands that are run against a platform that is not configured to error out.