Cannot activate non-cuda environment on non-cuda host

[kcajf]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

# pixi.toml

[project]
name = "test"
version = "0.1.0"
description = "test"
authors = ["test"]
channels = ["conda-forge"]
platforms = ["linux-64"]

[dependencies]
python = "3.12.*"

[feature.cuda.system-requirements]
cuda = "12.1"

[environments]
default = { features = [], solve-group = "default" }
cuda = { features = ["cuda"], solve-group = "default" }

pixi shell
Error:
  × The platform you are running on should at least have the virtual package __cuda on version 12.1, build_string: 0

Issue description

I have a pixi.toml that contains a default, non-cuda environment, and a cuda environment.
I was hoping to be able to use the default environment on non-cuda hosts, and use the cuda environment on cuda host.
Unfortunately, it seems like I'm unable to activate the default environment on a non-cuda host.

If I change the cuda environment to have a different solve-group, I am able to activate default on a non-cuda host, but I don't want to have a separate solve-group (I'd like the cuda env to be a strict extension of the other one).

Am I doing this wrong? I took some inspiration from the "Multiple machines from one project" example at https://pixi.sh/v0.20.0/features/multi_environment/#important-links

Expected behavior

I should be able to activate the non-cuda env on a non-cuda host.

[ruben-arts]

This is indeed a bug, we are checking the status of the solve-group not the environment you're running.

[kcajf]

Thanks @ruben-arts ! Good to hear.

[ruben-arts]

I'm sorry, this is my mistake to confuse the situation. But trying to actually fix it, the current state is actually logically correct.

When we solve with a solve group, you are getting packages in your result that might contain a dependency on the system-requirements specified for the complete group. So we can't currently fix this. However, we've already been picking at this problem for quite a while in #2849 which will most likely do what you want here.

A full solution will be that we solve the issue of making environments "similar" where you can have different dependencies based on extra requirements. Like having two "similar" environments where the version of python is different but all it's dependencies are kept the same if possible.

[kcajf]

I see, thanks.

Your last point sounds like what I want. In practice, I'd like to have some gpu-dependent library with a cpu and gpu version (e.g. pytorch and pytorch-gpu) each installed in their own environment - and have all other packages fixed to the same version.