CLI command can be lengthy and prone to errors (same as "docker run")

[130s]

Issue

By passing options, rocker shell command can be easily long and messy. Long commands and options can be prone to error. Users complain.

To help visualizing issue, I have a command that looks like this (note this example uses --volume option that's not yet merged https://github.com/osrf/rocker/pull/142). I'm sure there can be apps with more complexed commands:

$ export ENV_SETTER=~/env_setter_today.sh
$ rocker --x11  --nvidia --env-file $ENV_SETTER --volume /var/por/.config /var/lib/dbus/machine-id /home/cheesy/cap_data -- \
  registry.gitlab.com/foo.baa/app_img:imagerrr \
  roslaunch app_c bar.launch percep_ver:=8.2.1 \
  data_dir:=/home/cheesy/cap_data/tollson/0504/raw \
  show_display:=false

Potential resolution

• I'm tempted to ask "Is there a rocker-compose effort somewhere?". At minimum, the motivation of me saying is likely very simular why Docker community came up with compose.
  • However, making separate software on top of rocker can add more maintenance obviously.
  • Can rocker be passed to docker-compose? That sounds nice but I don't know if it's easily done...rocker re-defines some CLI arguments that are also defined in Docker CLI so I'm afraid passing args as-is not possible, hence my opinion earlier.

[tfoote]

There's not a plan for a rocker compose. Though I've been thinking about how to store required rocker arguments in the images using labels.

You could also write an extension that adds command line arguments specific to your workflow.

If you have a specific application which needs a bunch of standard arguments rocker is designed to be able to be extended with alternative entry points. For example I've written ghrocker: https://github.com/tfoote/ghrocker that takes advantage of the rocker API not the CLI.