[Request]: `container run`/`container create` should support a `--platform=<OS>/<ARCH>` flag

[euanh]

Feature or enhancement request details

The docker run and docker create commands take a --platform=<OS>/<ARCH> flag to select the OS and architecture of a multiarch image. container run and container create do not understand this flag; they expect separate --os <OS> and --arch <ARCH> flags. This means that it is not trivial for a script or tool to support both the docker and container CLIs at the same time.

podman supports both forms: --os <OS> / --arch <ARCH> and --platform <OS>/<ARCH> (the two forms are exclusive and only one or the other can be used in the same command). This makes it easy to substitute podman for docker in a script without rewriting it.

As an example, Swift SDK Generator currently uses the --platform flag here.

 OVERVIEW: Run a container

 USAGE: container run [<options>] <image> [<arguments> ...]

 ARGUMENTS:
   <image>                 Image name
   <arguments>             Container init process arguments

 OPTIONS:
   -w, --cwd, --workdir <cwd>
                           Current working directory for the container
   -e, --env <env>         Set environment variables
   --env-file <env-file>   Read in a file of environment variables
   --uid <uid>             Set the uid for the process
   --gid <gid>             Set the gid for the process
   -i, --interactive       Keep Stdin open even if not attached
   -t, --tty               Open a tty with the process
   -u, --user <user>       Set the user for the process
   -c, --cpus <cpus>       Number of CPUs to allocate to the container
   -m, --memory <memory>   Amount of memory in bytes, kilobytes (K), megabytes
                           (M), or gigabytes (G) for the container, with MB
                           granularity (for example, 1024K will result in 1MB
                           being allocated for the container)
   -d, --detach            Run the container and detach from the process
   --entrypoint <entrypoint>
                           Override the entrypoint of the image
   --mount <mount>         Add a mount to the container
                           (type=<>,source=<>,target=<>,readonly)
   --tmpfs <tmpfs>         Add a tmpfs mount to the container at the given path
   --name <name>           Assign a name to the container. If excluded will be a
                           generated UUID
   --remove, --rm          Remove the container after it stops
>  --os <os>               Set OS if image can target multiple operating systems
>                          (default: linux)
>  -a, --arch <arch>       Set arch if image can target multiple architectures
>                          (default: arm64)
   -v, --volume <volume>   Bind mount a volume into the container
   -k, --kernel <kernel>   Set a custom kernel path
   --cidfile <cidfile>     Write the container ID to the path provided
   --no-dns                Do not configure DNS in the container
   --dns <dns>             DNS nameserver IP address
   --dns-domain <dns-domain>
                           Default DNS domain
   --dns-search <dns-search>
                           DNS search domains
   --dns-option <dns-option>
                           DNS options
   -l, --label <label>     Add a key=value label to the container
   --disable-progress-updates
                           Disable progress bar updates
   --scheme <scheme>       Scheme to use when conntecting to the container
                           registry. One of (http, https, auto) (default: auto)
   --debug                 Enable debug output [environment: CONTAINER_DEBUG]
   --version               Show the version.
   -h, --help              Show help information.

Code of Conduct

• I agree to follow this project's Code of Conduct

[gigatexal]

Forgive my ignorance here I wonder if / how non arm support will work on future generations of MacOS given MacOS 26 will be the last release to support x86 and eventually Rosetta would be phased out.

Running non arm containers needs some sort of translation. Without Rosetta how would Apple do that? Or is there something in QEMU that can do it?

[tamird]

Possibly a related bug: when running container build . --platform linux/amd64 the error is Error: Unknown option '--platform', but when running container build --platform linux/amd64 . the error is Error: context dir does not exist linux/amd64. It should probably behave the same for both invocations.