feat: Implement det cmd describe

[gt2345]

Ticket

MD-139

Description

Implement det cmd describe so that user can use CLI to fetch metadata for a single command.
Also fix an error related to det cmd ls --csv

Test Plan

Start multiple commands using det cmd run ...
det cmd list would return the entire list of commands
Select one of the commands and pass it's ids to det cmd describe COMMAND_ID
You should only see selected command
Passing invalid id would display Failed to display command metadata
Other arguments such as --json/csv work as expected

Checklist

• Changes have been manually QA'd
• User-facing API changes need the "User-facing API Change" label.
• Release notes should be added as a separate file under docs/release-notes/.
  See Release Note for details.
• Licenses should be included for new code which was copied and/or modified from any external code.

[netlify]

✅ Deploy Preview for determined-ui canceled.

Name	Link
🔨 Latest commit	25c95cd
🔍 Latest deploy log	https://app.netlify.com/sites/determined-ui/deploys/667c423f3cddad00086e8dca

[codecov]

Codecov Report

Attention: Patch coverage is 11.11111% with 16 lines in your changes missing coverage. Please review.

Project coverage is 44.17%. Comparing base (da9025b) to head (25c95cd).
Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9500      +/-   ##
==========================================
- Coverage   49.79%   44.17%   -5.63%     
==========================================
  Files        1247     1205      -42     
  Lines      162235   159985    -2250     
  Branches     2888     2887       -1     
==========================================
- Hits        80793    70670   -10123     
- Misses      81270    89143    +7873     
  Partials      172      172              

Flag	Coverage Δ
harness	40.85% <11.11%> (-22.90%)	⬇️
web	46.16% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
harness/determined/cli/command.py	43.47% <ø> (ø)
harness/determined/cli/render.py	23.62% <50.00%> (-29.35%)	⬇️
harness/determined/cli/ntsc.py	22.96% <6.25%> (-30.92%)	⬇️

... and 200 files with indirect coverage changes

[NicholasBlaskey]

lgtm

[NicholasBlaskey]

nit: this is kinda hard for me to understand

maybe we could split this up into seperate if statements, like workspaceID does

[NicholasBlaskey]

nit: I think I prefer reqIDs being not a pointer, to match the style of reqUsers

[gt2345]

It would be nice to be consistent, but I wanted to make it optional and use nil for non command task

[azhou-determined]

i know the JIRA for this suggests supporting a list of IDs is a good idea, but i disagree. the use case for filtering a list of command tasks by a list of IDs seems really weak to me.

commands aren't really objects that are intended to be created and processed in large numbers or batches. you run commands usually as one-off processes for debugging or other manual tasks. i really can't imagine someone a) having enough commands that the list is large enough that filtering is necessary, and b) wanting to take the time to copy and paste a batch of UUIDs just to filter that list.

if we did want to support filtering on commands, we shouldn't do it by IDs. it'd be more sensible to accept a filter like workspace ID, or ordering parameters to sort by timestamps, etc.

filtering by IDs might make sense for a batch operation on something like checkpoints, where you often want to delete/download a known batch of IDs. but here we're just filtering them to render, and i highly doubt anyone will have more than 1 or 2 active command tasks at any point in time. seems like a silly feature to me, we don't support this for any other object, doesn't make sense to support it for commands.

my vote is that we just don't support passing multiple --ids. we can support describing a single command by ID with something like:
det cmd describe COMMAND_ID
which is in line with the rest of the CLI's conventions, and more than sufficient for this use case IMO.

[gt2345]

i know the JIRA for this suggests supporting a list of IDs is a good idea, but i disagree. the use case for filtering a list of command tasks by a list of IDs seems really weak to me.

commands aren't really objects that are intended to be created and processed in large numbers or batches. you run commands usually as one-off processes for debugging or other manual tasks. i really can't imagine someone a) having enough commands that the list is large enough that filtering is necessary, and b) wanting to take the time to copy and paste a batch of UUIDs just to filter that list.

if we did want to support filtering on commands, we shouldn't do it by IDs. it'd be more sensible to accept a filter like workspace ID, or ordering parameters to sort by timestamps, etc.

filtering by IDs might make sense for a batch operation on something like checkpoints, where you often want to delete/download a known batch of IDs. but here we're just filtering them to render, and i highly doubt anyone will have more than 1 or 2 active command tasks at any point in time. seems like a silly feature to me, we don't support this for any other object, doesn't make sense to support it for commands.

my vote is that we just don't support passing multiple --ids. we can support describing a single command by ID with something like: det cmd describe COMMAND_ID which is in line with the rest of the CLI's conventions, and more than sufficient for this use case IMO.

@azhou-determined Thanks for your comments, I agree with what you said and implement det cmd describe COMMAND_ID instead