There are a couple of differences in how docker-run and rocker work.
docker-run can be used in exactly the same way as the official docker run command. You can easily launch a container with docker-run defaults such as GUI forwarding or GPU support enabled, but at the same time also pass other Docker-native options such as port exposition or volume mounting. Note that docker-run only sets runtime flags for launching a new container of an existing image.
rocker always builds a dedicated new Docker image based on a given base image. At the same time, it also sets the required runtime flags (similar to docker-run) for enabling things like GPU support. This definitely slows down the initial launch process a bit, since a new image is either built or read from image cache each time. On the other hand, this approach allows rocker to inject some installation steps into the base image.
We feel like docker-run covers most of rocker’s features, even though it is only setting runtime flags for starting the container. One noteworthy feature of rocker is that it sets up a new user with appropriate permissions in the image that is built, such that no permission conflicts between host user files and container files arise. While docker-run cannot solve this problem on its own through runtime flags, its docker-ros plugin also solves permission errors by setting up a new user on-the-fly during container launch. This works with compatible images such as our docker-ros-ml-images or the ones built by docker-ros.
One last highlight of docker-run is that in principle is doesn’t relate to ROS at all, but is useful for any kind of Docker container.