Create a ROS 1 equivalent of osrf/ros2:devel

[mikaelarguedas]

It's not uncommon to see people writing their own image from scratch because the ROS images bring in too many dependencies.

While the ROS docker images are thought of as "for deployment" there is a strong use case for CI systems or environments for building packages.

Similarly to how we provide a osrf/ros2:devel image for ROS 2, we could consider providing a set of devel images for ROS 1.
These images would :

• be distro specific: osrf/ros:devel-kinetic osrf/ros:devel-noetic-buster
• have the ROS apt repo setup
• install the released version of catkin for the corresponding distro
• install the dependencies listed at https://wiki.ros.org/melodic/Installation/Ubuntu#Installation.2FUbuntu.2FBinariesBuildDependencies.Dependencies_for_building_packages
• have rosdep initialized and installed
• have catkin_tools installed ?

[ruffsl]

Similarly to how we provide a osrf/ros2:devel image for ROS 2, we could consider providing a set of devel images for ROS 1.

Think similarly using a separate repo, e.g. osrf/ros1 to host more exotic tags would be best, as not to convolute the general osrf/ros docker repo.

[Rayman]

@mikaelarguedas have you seen the ros:noetic-ros-base image? What does it contain that is too much in your opinion? There is also ros:noetic-ros-core which is even smaller`.

[mikaelarguedas]

Think similarly using a separate repo, e.g. osrf/ros1 to host more exotic tags would be best, as not to convolute the general osrf/ros docker repo.

Fair enough, although naming it ros1 may be misleading, it's already confusing that there are the ones on the official library and the ones in the osrf profile.
Maybe something like ros1-dev or something like that ?

mikaelarguedas have you seen the ros:noetic-ros-base image? What does it contain that is too much in your opinion? There is also ros:noetic-ros-core which is even smaller`.

In general even ros_core comes with a lot of stuff. It was trimmed a bit recently but there is still a significant set of dependencies that one does not need for building packages, e.g. the rosbash commandline tools, all language message generators, or all the common_msgs. Many people will need a subset, but they would(/should) define what they need in their package.xml.

You can think of this as an environment to build ROS packages but without any ROS package installed in it: you install and build what you need and nothing else

[ruffsl]

Fair enough, although naming it ros1 may be misleading, it's already confusing that there are the ones on the official library and the ones in the osrf profile.
Maybe something like ros1-dev or something like that ?

I think keeping with the precedent we've started with osrf/ros2:devel would make osrf/ros1:devel more obvious. The library/ros and osrf/ros repos should be reserved for releases specific tags. Although, if there were to be library/ros:<distro>-devel, that may placate the desire for CI/development images with only minimal packages installed. Although we then wouldn't be able to rebuild them every day like we do with osrf/ros2:devel, so perhaps that would be a cause for keeping them under our the org, e.g osrf/ros:<distro>-devel.

Would we want the devel related tags to be rebuilt everyday, so they get patches to rosdep, colcon, catkin, vcs, etc quickly, or should they be thought as any other installed debian package.

Also, with no more ROS1 releases, would there still be a need for a generic osrf/ros1:devel like we have with osrf/ros2:devel and osrf/ros2:nightly, rather than say just a osrf/ros:noedic-devel?

[mikaelarguedas]

I dont think we want them to be in the library because we'd want to modify or rebuild as we see fit.

osrf/ros2:devel is on ros2 mostly because we had a ros2 profile already that was used for hosting the ros2 distro images before moving them to the official lib + the osrf/ros repo. So it was not much of a choice but more of a consequence of what was already there.
As the naming got confusing since ROS 2 images got moved to the ros repo. I'm thinking this can be a good opportunity to revisit where to store the existing developement images currently on osrf/ros2 and if having one single repo for all dev images (ros1 and ros2) that has dev in the name could help disambiguate.

Would we want the devel related tags to be rebuilt everyday, so they get patches to rosdep, colcon, catkin, vcs, etc quickly, or should they be thought as any other installed debian package.

I was thinking the former although there is a lot less activity on the ROS1 tools so the impact would be smaller. Maybe we could use an approach similar to the one envisioned in #376 and trigger rebuild if we detect that the hash of any of these installed packages has changed.
Remotely related: I think these should setup the ros2-testing repo by default and not the ros2 (main) one.

Also, with no more ROS1 releases, would there still be a need for a generic osrf/ros1:devel like we have with osrf/ros2:devel and osrf/ros2:nightly, rather than say just a osrf/ros:noedic-devel?

I think there would still be a need to be able to run CI on an array of ROS Distro and OSes. Supporting melodic CI is also an important thing IMO, kinetic is getting close to EOL but ci is still a good thing to have and wouldnt cost much to support as well..
As active ROS distros dont have overlapping OSes anymore, we could afford to have less verbose names:

ros1:devel-bionic  # same as ros:melodic-devel-bionic
ros1:devel-stretch  # same as ros:melodic-devel-stretch
ros1:devel-focal  # same as ros:noetic-devel-focal
ros1:devel-buster  # same as ros:noetic-devel-buster

or something of the sort:

ros-dev:ros1-devel-focal  # used for noetic testing
ros-dev:ros2-devel-focal # used for any ROS2 focal based distro (Foxy, G-turtle)
...

[ruffsl]

osrf/ros2:devel is on ros2 mostly because we had a ros2 profile already that was used for hosting the ros2 distro images before moving them to the official lib + the osrf/ros repo. So it was not much of a choice but more of a consequence of what was already there.
As the naming got confusing since ROS 2 images got moved to the ros repo.

While some of that was the case, I've been hesitant to add anymore tags to the osrf/ros repo that do not equate to respective Debian meta packages. For experimental and development images, I've always tried to keep this distinction by placing them in an explicit ros2 repo.

Remotely related: I think these should setup the ros2-testing repo by default and not the ros2 (main) one.

Is that something we should retrofit with the existing ros2 dev tags, and similarly do for ros1 dev tags? Are there any potential cons you can think of?

As active ROS distros dont have overlapping OSes anymore, we could afford to have less verbose names

I think keeping with the existing pattern would lend it to be more interchangeable with existing tags, e.g. if someone was using ARGs to programmatically switch between library/ros:melodic-ros-base-bionic osrf/ros1:melodic-devel-bionic.

...
FROM $REPO:$ROS_DISTRO-$META-$OS_DISTRO

[mikaelarguedas]

I've been hesitant to add anymore tags to the osrf/ros repo that do not equate to respective Debian meta packages. For experimental and development images, I've always tried to keep this distinction by placing them in an explicit ros2 repo.

couldn't agree more, I'm just suggesting that, now that all the Debian metapackages matching images are all on the osrf/ros repo, that we place all the experimental / dev images on a ros-version-agnostic osrf/ros-dev repo and remove the now unnecessary distinction between 1 and 2.

Is that something we should retrofit with the existing ros2 dev tags, and similarly do for ros1 dev tags? Are there any potential cons you can think of?

I think we should. No cons off the top of my head. I'm actually surprised because I thought we were using that repo already...
Apparently we use it in the nightly images but not the devel ones:

docker_images/ros2/nightly/nightly/Dockerfile

Line 27 in 9c602bc

RUN echo "deb http://packages.ros.org/ros2-testing/ubuntu `lsb_release -sc` main" > /etc/apt/sources.list.d/ros2-testing.list

think keeping with the existing pattern would lend it to be more interchangeable with existing tags, e.g. if someone was using ARGs to programmatically switch between library/ros:melodic-ros-base-bionic osrf/ros1:melodic-devel-bionic.

That makes sense to me 👍

Would we do the same for ROS 2 ? If so we'll end up creating new duplicated/aliased images:
osrf/ros-dev:dashing-devel-bionic and osrf/ros-dev:eloquent-devel-bionic that would be identical under the hood?.

[ruffsl]

that we place all the experimental / dev images on a ros-version-agnostic osrf/ros-dev repo and remove the now unnecessary distinction between 1 and 2.

But we don't have ros1 equivalents to nightly. It may be fine to move distro specific tags to a ros-devel distro agnostic repo, but having a 1 vs 2 repo separation still has a place for distro agnostic tags like nightly. I think making the distinction via the repo name rather than the tag name is fine for 1 vs 2 as the tags are not as interchangeable given the difference in development environments.

Would we do the same for ROS 2 ? If so we'll end up creating new duplicated/aliased images:
osrf/ros-dev:dashing-devel-bionic and osrf/ros-dev:eloquent-devel-bionic that would be identical under the hood?.

Duplicate tags for one image are not hard to make or use, but they are a bit harder to manage in the registry, as it may necessitate fancy post build hooks for Dockerhub to tag/push an image more than once. Not sure how to best integrate that at present.

[ruffsl]

With the migration of ROS2 to Ubuntu jammy, we'll soon have a scenario where there will be no accompanying ROS1 distro targeting the same OS as the latest ROS2 distro. Would it be worth while to revisit this to provide a simple containerized method of source building ROS1 for say maintaining a ros1 bridge?