@ruben-arts This is ready to be reviewed.

I updated the branch to fix some other issues, for testing.

Hey @prady0t,

I was testing with this toml file:

[workspace]
channels = []
platforms = ["osx-arm64"]

[tasks]
test = "echo test"
test2 = "echo test2"
dep.depends-on = ["test3", "test6"]

[feature.test.tasks]
test3 = { cmd = "echo test3", default-environment = "three" }
test4 = "echo test4"

[feature.test2.tasks]
test5 = "echo test5"
test6 = { cmd = "echo test6", default-environment = "four" }

[environments]
one = []
two = ["test"]
three = ["test2", "test"]
four = ["test2"]
five = ["test", "test2"]
six = { features = ["test"], no-default-feature = true}
seven = { features = ["test2"], no-default-feature = true}

But in no case would it actually use the default-environment.

Could you test it yourself and add some tests.

The other decisions you made look fine to me, so I'm looking forward to testing them.

For me, it just gives different environments where tests could be run.

Please select an environment to run the task in: ›
❯ two
  three
  five
  six

Let me find a way to use the specified default environment when the task can be solved for multiple environments.

Let me find a way to use the specified default environment when the task can be solved for multiple environments.

I might have misunderstood, but isn't that the whole idea of this feature?

I might have misunderstood, but isn't that the whole idea of this feature?

Exactly. Currently, the default-environment is applied after task resolution, and hence, if multiple environments are specified, it prompts the user. Due to task ambiguity

There's another bug for the same manifest; remove the default-environment part for test3 and run with the -e three flag; the user still gets prompted for multiple environments. Is that desired behaviour? If so i just checked if explicit_environment is provided or not; if not, treat default_environment as explicit environment.

The current bug can be fixed by adding a check for a task with default_environment in disambiguate_task_interactive in run.rs, but how should the -e flag be treated after that?

@ruben-arts these changes should be good to go. I've also added a few tests.

The latest changes don't work for overriding the default environment yet.

[workspace]
channels = []
platforms = ["osx-arm64"]

[tasks]
test = { cmd = "echo test", default-environment = "test" }

[feature.test.dependencies]
# pytest = "*"

[environments]
test = ["test"]

Gives:

> pixi run test
✨ Pixi task (test in default): echo test                                                                                                         
test

While I expected it to run in test.

Added a check for when the task is in default and default-environmnet is added.

tested with both pixi.toml that you guys have attached. Also verified if priorities with -e or default-environment are respected - everything works fine.