Confused with Go Templates, and I want podman's Go-lang people to hear about it.

[EvanCarroll]

Issue Description

I don't believe the documentation on --format is clear enough, nor do I think it can be made clear enough to accommodate for the complexity of Go's templates.

Steps to reproduce the issue

Steps to reproduce the issue

1. podman run -d -p 1234:1234 --name evanrox alpine:3 sleep 360
2. podman inspect evanrox
3. podman inspect evanrox --format '{{ .NetworkSettings.Ports }}'
4. podman inspect evanrox --format '{{index .NetworkSettings.Ports "1234/tcp" 0 }}'

Describe the results you received

Using the above steps, in

• 2, you get the stringification provided by Go's map.
• 3, you target a map and you get the stringification provided by Go's map.
• 4, you target a struct and you get either
  • the stringification provided by default Go's struct.
  • a custom stringification provided by the developers.

The workflow people will use when they're using podman inspect or jq is to iteratively refine the query until they get to the data they want. Go makes this very complex because if you get a map, you'll know how to further refine. But if you get a struct, you're stuck with {value1, value2} and it's not clear how to refine. This is what happened here, which I later found out was because of this.

The only solution I can think to this, is a very strong and bold suggestion that if using Go's --format and --filter, you should always use make your first step in trouble-shooting to use json, ie.,

If

podman inspect evanrox --format '{{ index .NetworkSettings.Ports "1234/tcp" 0 }}'

Doesn't make it clear to you what's wrong, you should immediately grab,

podman inspect evanrox --format '{{ json ( index .NetworkSettings.Ports "1234/tcp" 0 ) }}'

Putting it another way DO NOT TROUBLESHOOT WITH THE DEFAULT OR CUSTOM STRING IMPLEMENTATIONS USING FILTER, TROUBLESHOOT WITH json's STRING IMPLEMENTATION

Describe the results you expected

I would expect everything to use the stringification provided by map, and consistently. And not to change the implementation of stringify depending on the type of data that the template returned.

podman info output

❯ podman info
host:
  arch: amd64
  buildahVersion: 1.28.2
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_100:2.1.0-2_amd64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 89.8
    systemPercent: 1.22
    userPercent: 8.98
  cpus: 8
  distribution:
    codename: bookworm
    distribution: debian
    version: "12"
  eventLogger: journald
  hostname: x1c7
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.1.0-18-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 1427849216
  memTotal: 16476053504
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun_100:0.18-2_amd64
    path: /usr/bin/crun
    version: |-
      crun version 0.18.1-7931a-dirty
      commit: 7931a1eab0590eff4041c1f74e2844b297c31cea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_100:1.1.8-3_amd64
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 16078434304
  swapTotal: 16823349248
  uptime: 63h 26m 14.00s (Approximately 2.62 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/ecarroll/.config/containers/storage.conf
  containerStore:
    number: 23
    paused: 0
    running: 2
    stopped: 21
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/ecarroll/.local/share/containers/storage
  graphRootAllocated: 1950487011328
  graphRootUsed: 522896461824
  graphStatus: {}
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 4
  runRoot: /run/user/1000/containers
  volumePath: /home/ecarroll/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 0
  BuiltTime: Wed Dec 31 18:00:00 1969
  GitCommit: ""
  GoVersion: go1.19.8
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

### Podman in a container

No

### Privileged Or Rootless

Rootless

### Upstream Latest Release

Yes

### Additional environment details

Additional environment details

### Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[Luap99]

I would expect everything to use the stringification provided by map, and consistently. And not to change the implementation of stringify depending on the type of data that the template returned.

This is not a bug and works as expected. We have no control over the output from the go std lib and how it renders structs vs maps, etc...
Asking for better docs is fine (#17676) but we cannot change the output.