If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Command grouping, run-levels, and/or preconditions

NEW
Unassigned

Status

()

Core
mach
5 years ago
5 years ago

People

(Reporter: gps, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
From bug 818457 comment 17:

Another idea I've been tossing around in my head is the ability for mach commands to define a "can I run" function or separate run levels. For the majority of commands, this would be a simple shared heuristic of "is the tree built?" The mach driver could test whether the requested command is allowed to run given the current state of the world. If not, it prints a nice helpful error message saying what needs to happen. A similar design has mach commands organized into categories or having labels. Each of those defines preconditions for execution. There are a number of ideas here.

---

This bug will track that.

There are a number of ways we can go about this. I see an inevitable need for mach commands to be grouped for organization in the help output. Otherwise, as the number of commands grows, the list will just become confusing, IMO. It's certainly tempting to associate preconditions or run levels with each grouping. Although, that could be fragile in practice.

I'm currently leaning towards just implementing per-command preconditions. There would exist a decorator (say @CommandPrecondition) whose argument(s) would be callables.

At command dispatch time (or even |mach help| time), the dispatch mechanism would call the precondition function(s). If they fail, an error message is printed (likely provided by the precondition function) and mach exits gracefully. Else, the command is allowed to continue.

I'm interested in what others think the design should be.
You need to log in before you can comment on or make changes to this bug.