refactor app list to make more usable

[lucarin91]

app list is both the place that show examples apps and the status of them, e.g. start, stop ecc. With the new inclusing of core-and-fundamenta examples and the bricks examples, this command is very full of stuff, and it is almast unusable.

I think we should start thinking to add a app ps command to show only active apps and add some filter on the app list to make that more usable.

[kirbx01]

I’d like to work on this but I reviewed the current app-listing implementation and noticed that ListAppRequest already supports StatusFilter.

I’m thinking we could expose that through app list --status <status> and add app ps as a shorthand for listing running apps, while reusing the existing ListApps implementation rather than duplicating the logic. I’ll also add tests for the new filtering behavior.

Does this approach fit the intended direction, or i need to amend something? Would love your suggestions before starting to work on this.

[lucarin91]

I’d like to work on this but I reviewed the current app-listing implementation and noticed that ListAppRequest already supports StatusFilter.

I’m thinking we could expose that through app list --status <status> and add app ps as a shorthand for listing running apps, while reusing the existing ListApps implementation rather than duplicating the logic. I’ll also add tests for the new filtering behavior.

Does this approach fit the intended direction, or i need to amend something? Would love your suggestions before starting to work on this.

Hi, thanks for the interest in this issue. If you are interested in working on it, I think I would need to be more precise on the scope of this improvement. My goal here is to split the app catalog from the app status command; this was something we also wanted to do at the beginning of the project, but it was simplified for varius reason to a single app list command, with a filter, but I think now show its limit.

So I would split this issue into two separated effort: one providing a better view of the live apps that are on the board, aka the ps command, and the other is to simplify the list command, aka the catalog.

I think the app ps command should have the following layout and output:

app ps              # live + failed
app ps --all / -a   # also stopped

ID                NAME         STATUS       
user:my-app       My app       running    
user:door-counter Door counter failed   

So by default only starting, running, stopping, and failed applications are shown, and like Docker with --all, we also show the stopped application, excluding in all combinations the uninitialized ones.
Regarding implementation, I think this command should internally use the getAppsStatus utility, which uses Docker to gather status information on applications initialized at least once.
In the future, I would also foresee some useful additions like the port of an exposed web UI, or more details regarding failing brick containers, e.g., failed (2/3 bricks).

Instead, the app list will become a pure catalog view, so I would probably remove the status column and provide filters to get only user applications and/or examples.

app list            # user apps
app list --examples # examples only
app list --all / -a # both

ID                NAME         DESCRIPTION
user:my-app       My app       Reads the sensor and posts to the cloud
user:door-counter Door counter Counts people through the door

So by default I would return only the user application, with the --examples flag only examples, and with --all both of them.
The emoji column is creating so many indentation issues on different terminals that I would also remove; not sure it is adding much anyway.