Skip to content

fix(task): correct task list runnability and show every task#6367

Open
hunger wants to merge 2 commits into
prefix-dev:mainfrom
hunger:push-nsxmkzvptnto
Open

fix(task): correct task list runnability and show every task#6367
hunger wants to merge 2 commits into
prefix-dev:mainfrom
hunger:push-nsxmkzvptnto

Conversation

@hunger

@hunger hunger commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

pixi task list derived an environment's runnability from the conda-meta/pixi install marker, which records the platform a previous install resolved for and goes stale when the manifest changes -- so tasks were reported runnable "by design" for an environment the current manifest can no longer install. It also dropped environments it deemed unsupported and had no way to represent an environment with no dependencies at all.

Classification now ignores the install marker and works from the manifest and lock file:

  • an environment with no dependencies reports "no dependency" -- nothing it installs can require a virtual package the machine lacks;
  • otherwise it is "by design" when the machine satisfies a declared platform's virtual packages, "by accident" when it only meets the locked packages' minimum, and "unsupported" when it meets neither.

task list now prints every task in one table with a Status column, dimming tasks whose environment cannot run here instead of hiding them.

Fixes: #1347

How Has This Been Tested?

By experimenting with a test project (and a new test)

AI Disclosure

  • This PR contains AI-generated content.
    • I have tested any AI-generated content in my PR.
    • I take responsibility for any AI-generated content in my PR.

Tools: Claude

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added sufficient tests to cover my changes.
  • I have verified that changes that would impact the JSON schema have been made in schema/model.py.

@hunger

hunger commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

@ruben-arts: I would appreciate feedback on the output itself. This is what the output looks like now, so you do not have to built it for a first impression:

🧚 v0.70.2 ⬢ [pixi] ➜ pixi task list
Task   Status       Description
task1  by design    TASK 1
task2  by design
task3  unsupported
task4  by accident  This is task 4 with a longer description than the other tasks
🧚 v0.70.2 ⬢ [pixi] ➜

The unsupported entries are greyed out, but that does not show anymore after copy and pasting the text.

It will always list all task, but classify whether those can be run.

no dependency run in an empty environment. Those are host only, so they should work on any host in theory.
by design are those where the current platform matches or exceeds the platform the environment was resolved for.
by accident are those tasks that run in an environment where the current platform matches or exceeds the minimum required platform defined by looking at all the packages in the environment, but no not matches the resolved platform.
unsupported is should not run on the current machine at all.

Note: You can always pixi install --platform=whatever to materialize the environment and then give running the tasks a try -- independent what this says will work or not.

@hunger hunger requested a review from ruben-arts June 15, 2026 16:40
@hunger

hunger commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

The tests fail as I introduced a small behavior change: If there are no dependencies, I always assume a test can run, as it is by necessity entirely based on host binaries.

This breaks the tests introduced to validate that we fail fast on an unsupported platform.

I am unsure whether I should change the test to depend on some small binary, thus getting marked as unsupported or remove the "no dependency" special case I introduced here. I added it since I found it confusing to have a lot of tasks going "unsupported", just because I forgot to add a dependency.

If we leave the "no dependency" case, then we should probably not fail trying to install an empty environment as unsupported though. That feels like going a bit for for this change... we would need to reach consensus first on what should actually happen in this corner-case.

@hunger hunger force-pushed the push-nsxmkzvptnto branch 2 times, most recently from 587d5e5 to 5ebfdb4 Compare June 30, 2026 15:09
hunger added 2 commits June 30, 2026 15:19
Show every task in `pixi task list` and dim the ones whose environment
cannot run on the current machine. Fixes the runnability check so tasks
are no longer wrongly omitted.
@hunger hunger force-pushed the push-nsxmkzvptnto branch from 5ebfdb4 to 43f609c Compare June 30, 2026 15:20
@hunger

hunger commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

The no-dependency case is now assumed to always work: It is by definition using the host-provided binaries and we assume those will run on the host.

@hunger

hunger commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

We had quiete a few stability fixes, so this change is stable now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Starting from pixi-0.21.0 pixi task list will fail if system-requirements do not comply, but without saying so

1 participant