cli: print module object fields with dagger call

[helderco]

Fixes #6514
Fixes #6515

Previously, when a dagger call chain ended in an object, the result was inconsistent and not very useful:

• Without any functions, it would show --help
• Container, Directory and File core types evaluated the pipeline and returned a "XXX evaluated." message
• For custom user types, an error was returned: "return type XXX requires a sub-command"

With this change, in all of those cases, the CLI finds all functions without required arguments that return a scalar/primitive value, and prints them. This includes a module's main object, when calling dagger call without any more arguments.

Note

At minimum, a _type field is added to the response so there's always something to show.
When not a TTY, --json format is used instead of the more human-readable default format.

See following examples.

Module’s main object

Before

❯ dagger call
[output of --help]

After

❯ dagger call
_type: Playground
baseImage: python:3.12-alpine
cacheKey: playground-cache

Object with no available functions

Before

❯ dagger call bar
Error: invalid selection for command "bar": return type "PlaygroundBar" requires a sub-command
Run 'dagger call bar --help' for usage.
exit status 1

After

❯ dagger call bar
_type: PlaygroundBar

Container

Before

❯ dagger call container
Container evaluated. Use "dagger call container --help" to see available sub-commands.

After

❯ dagger call container
_type: Container
defaultArgs:
    - /bin/sh
entrypoint: []
mounts: []
platform: linux/arm64
stderr: ""
stdout: |
    NAME="Alpine Linux"
    ID=alpine
    VERSION_ID=3.20.0
    PRETTY_NAME="Alpine Linux v3.20"
    HOME_URL="https://alpinelinux.org/"
    BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
user: ""
workdir: ""

Directory

Before

❯ dagger call container directory --path=/etc/ssl
Directory evaluated. Use "dagger call echo directory --help" to see available sub-commands.

After

❯ dagger call container directory --path=/etc/ssl
_type: Directory
entries:
    - cert.pem
    - certs
    - ct_log_list.cnf
    - ct_log_list.cnf.dist
    - openssl.cnf
    - openssl.cnf.dist
    - private

File

Before

❯ dagger call container file --path=/etc/os-release
File evaluated. Use "dagger call echo file --help" to see available sub-commands.

After

❯ dagger call container file --path=/etc/os-release
_type: File
name: os-release
size: 188

List of containers

Before

❯ dagger call containers
Error: "containers" requires a sub-command
Run 'dagger call foo containers --help' for usage.
exit status 1

After

❯ dagger call containers
- _type: Container
  defaultArgs:
    - /bin/sh
  entrypoint: []
  mounts: []
  platform: linux/arm64
  stderr: ""
  stdout: |
    NAME="Alpine Linux"
    ID=alpine
    VERSION_ID=3.20.0
    PRETTY_NAME="Alpine Linux v3.20"
    HOME_URL="https://alpinelinux.org/"
    BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
  user: ""
  workdir: ""
- _type: Container
  defaultArgs:
    - /bin/sh
  entrypoint: []
  mounts: []
  platform: linux/amd64
  stderr: ""
  stdout: |
    NAME="Alpine Linux"
    ID=alpine
    VERSION_ID=3.20.0
    PRETTY_NAME="Alpine Linux v3.20"
    HOME_URL="https://alpinelinux.org/"
    BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
  user: ""
  workdir: ""
- _type: Container
  defaultArgs:
    - /bin/sh
  entrypoint: []
  mounts: []
  platform: linux/386
  stderr: ""
  stdout: |
    NAME="Alpine Linux"
    ID=alpine
    VERSION_ID=3.20.0
    PRETTY_NAME="Alpine Linux v3.20"
    HOME_URL="https://alpinelinux.org/"
    BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
  user: ""
  workdir: ""

[helderco]

Added a _type field to the response with the object's name so there's always something to show that's useful, instead of returning an error.

[sourishkrout]

Heads up, when the final leaf happens to be a binary File the contents basically dumps the file into the terminal. Bit of usability issue.

[shykes]

Could we change the default to pretty-printed json, with (perhaps) a global flag to change the format to yaml? I think it would be more convenient for scripting, piping into jq etc

[helderco]

Could we change the default to pretty-printed json, with (perhaps) a global flag to change the format to yaml? I think it would be more convenient for scripting, piping into jq etc

It's already supported via the -f json flag (replaces --json). The reason yaml is the default it's because it was made to be human readable, while json is targeted for machines. I also think yaml is better for displaying multi-line strings. It won't look good in json.

[shykes]

The reason yaml is the default it's because it was made to be human readable, while json is targeted for machines

It's true that it makes sense to pretty-print. Then I have 2 requests:

1. Can we keep --json | -j as a convenience for --format json? It deserves special treatment as json output is the gold standard when scripting, and we are trying to improve the scripting experience. It would certainly be less keystrokes for me..

2. If the default output is "human friendly pretty-print", we must protect the freedom to iterate on that output. If our first implementation of a pretty-print is simply yaml, as a convenience, then we should tweak the output to just enough that it is not compliant yaml - just yaml-ish. If never make the promise that the output is compatible yaml, we won't break that promise later. This keeps the door wide open for innovating on the best output in the future, TUI-style. (thanks @aluzzardi for the suggestion)

[shykes]

If never make the promise that the output is compatible yaml, we won't break that promise later. This keeps the door wide open for innovating on the best output in the future, TUI-style

Any thoughts on this part @vito ? :)

[sourishkrout]

1. Can we keep --json | -j as a convenience for --format json?

I'd be fantastic if there was also a way to set this via an ENV var too, please.

[vito]

@shykes

Any thoughts on this part @vito ? :)

Agree - ideally the TUI can render objects however it wants without worrying about compatibility. But it seems like compatibility should only matter when the output is going to a machine, so maybe we just infer that from stdout?

• If stdout is a pipe/file, emit JSON.
• If stdout is a TTY, emit some human-compatible format.

At that point we could probably still do YAML as an implementation detail, since you if you try to capture it you'll get JSON instead (...which is also valid YAML! 🤓) - but if we're still concerned (or just Team No-YAML) we could do some small tweak like you suggest.

[helderco]

If the default output is "human friendly pretty-print", we must protect the freedom to iterate on that output. If our first implementation of a pretty-print is simply yaml, as a convenience, then we should tweak the output to just enough that it is not compliant yaml - just yaml-ish. If never make the promise that the output is compatible yaml, we won't break that promise later. This keeps the door wide open for innovating on the best output in the future, TUI-style. (thanks @aluzzardi for the suggestion)

How about I revert the --format flag and keep only --json, using yaml as an implementation detail? Switching to --json automatically based on tty or not too.

[helderco]

How about I revert the --format flag and keep only --json, using yaml as an implementation detail? Switching to --json automatically based on tty or not too.

I made this change. I don't think it's necessary to make sure the default format is invalid yaml. "yaml" isn't mentioned anywhere nor is given as an option so it's an implementation detail that can't be relied on.

Heads up, when the final leaf happens to be a binary File the contents basically dumps the file into the terminal. Bit of usability issue.

Not sure what to do with this. Is it a blocker or can it be improved in a follow up?

[shykes]

How about I revert the --format flag and keep only --json, using yaml as an implementation detail? Switching to --json automatically based on tty or not too.

I made this change.

👍🙏

I don't think it's necessary to make sure the default format is invalid yaml. "yaml" isn't mentioned anywhere nor is given as an option so it's an implementation detail that can't be relied on.

👍🙏

Heads up, when the final leaf happens to be a binary File the contents basically dumps the file into the terminal. Bit of usability issue.

Not sure what to do with this. Is it a blocker or can it be improved in a follow up?

Ideally contents would return a type like ByteStream or Bytes. If we can figure out the correct behavior for a leaf of that future type, then we can pretend contents has that type, and adopt that behavior now.

[shykes]

Heads up, when the final leaf happens to be a binary File the contents basically dumps the file into the terminal. Bit of usability issue.
Ideally contents would return a type like ByteStream or Bytes. If we can figure out the correct behavior for a leaf of that future type, then we can pretend contents has that type, and adopt that behavior now.

@helderco I would skip File.contents for now. That way we can always revisit later without breaking anyone. That way we can merge this :)

[helderco]

@helderco I would skip File.contents for now. That way we can always revisit later without breaking anyone.

Updated and rebased. Waiting for checks to pass.