Can the ROS1 dockerfiles provide ROS_PYTHON_VERSION?+

[Rayman]

I'm migrating to noetic. On my system I can use $ROS_PYTHON_VERSION as this is provided by the ros_environment package. But during the build of a Dockerfile this variable is not provided, only after sourcing of the workspace.

Can you provide $ROS_PYTHON_VERSION during the build? I'm willing to contribute a PR for this.

As a workaround I'm using

RUN source "/opt/ros/$ROS_DISTRO/etc/catkin/profile.d/1.ros_python_version.sh" \
    && python$ROS_PYTHON_VERSION somescript

[mikaelarguedas]

We do try not to duplicate the definition of environment variable in the Dockerfiles so we set only the one required to build the image itself.

So we do not set any ROS env variable other than ROS_DISTRO.
However when you start the container, the environment is setup via the entrypoint.

---

On the other hand we were discussing the necessity of retrieving the ROS_VERSION and ROS_PYTHON_VERSION from the rosdistro index. So once we have them it shouldn't cost much to set them in the dockerfile as these are not meant to change for the lifetime of the ROS distribution.
@ruffsl WDYT?

[ruffsl]

However when you start the container, the environment is setup via the entrypoint.

True, it's becoming common to source the setup.sh file too before invoking commands that expect a sourced environment.

as these are not meant to change for the lifetime of the ROS distribution.

Yea, I can't think of a common use case that would need to change it or have it unset.

[mikaelarguedas]

True, it's becoming common to source the setup.sh file too before invoking commands that expect a sourced environment.

Then it may get more misleading:
"So ... ROS_DISTRO and ROS_PYTHON_VERSION are set but not ROS_PACKAGE_PATH"
So we'll need to decide where to draw the line.

This is all the ROS stuff set in the environment for noetic as a reference:

$ docker run -it --rm ros:noetic-ros-core
root@0b796ab1030f:/# env | grep -i ROS
ROS_VERSION=1
PKG_CONFIG_PATH=/opt/ros/noetic/lib/pkgconfig
ROS_PYTHON_VERSION=3
ROS_PACKAGE_PATH=/opt/ros/noetic/share
ROSLISP_PACKAGE_DIRECTORIES=
ROS_ETC_DIR=/opt/ros/noetic/etc/ros
CMAKE_PREFIX_PATH=/opt/ros/noetic
PYTHONPATH=/opt/ros/noetic/lib/python3/dist-packages
ROS_MASTER_URI=http://localhost:11311
LD_LIBRARY_PATH=/opt/ros/noetic/lib
PATH=/opt/ros/noetic/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ROS_ROOT=/opt/ros/noetic/share/ros
ROS_DISTRO=noetic

[ruffsl]

So we'll need to decide where to draw the line.

Yea, that make me lean toward just suggesting fokes to source the setup, as setting all those paths and default ENVs could screw with sourcing different setup files, like ros1_bridge, or when using multiple workspace overlays.

[gavanderhoorn]

I've always just prefixed commands in containers with /opt/ros/$ROS_DISTRO/env.sh, which seems to take care of all of this.

It's basically the same as the entrypoint I believe, but also works with workspaces.

[mikaelarguedas]

👍 yes this is what I use too.

---

I believe what ruffsl meant by

it's becoming common to source the setup.sh file too before invoking commands that expect a sourced environment.

Was that if users in general end up "often/always prefixing commands with it" (which seems to be your case) it may be a reason for providing an already set up environment in the container.

But as pointed above it may be too intrusive so documenting this alternative for users will be the way to go.
The upcoming examples in the doc will use such an approach. Do we think it's enough or should we come up with a more visible example ?

Another thing we could consider: provide a utility command/alias to keep it less verbose and error-prone. (there is often reports of people trying to source and failing because source is a bash command). I could imagine something called rosenv that people could use in dockerfile

RUN rosenv && catkin build ...

[ruffsl]

Another thing we could consider: provide a utility command/alias to keep it less verbose and error-prone. (there is often reports of people trying to source and failing because source is a bash command). I could imagine something called rosenv that people could use in dockerfile

Well, such a utility could help make Dockerfile directives and instructions more shell agnostic, but how would in know which path setup source to replicate in the environment? Simply prefixing ros related directives using . setup.sh seems to cover most conventional Docker uses.

[mathias-luedtke]

I could imagine something called rosenv that people could use in dockerfile

I would prefer, if you would name differently..
https://github.com/ros-industrial/industrial_ci/blob/master/industrial_ci/src/util.sh#L49
(In our case, it chooses the right workspace in the chained order)

I've always just prefixed commands in containers with /opt/ros/$ROS_DISTRO/env.sh

IMHO this is the best approach. It states clearly which environment is used.
Unfortunately, ROS2 and ROS1 colcon-built workspaces do not have this file (yet)..

[ruffsl]

What's the practical difference between setup.sh and env.sh files in an installed workspace?

[mikaelarguedas]

Unfortunately, ROS2 and ROS1 colcon-built workspaces do not have this file (yet)..

Do you know if there is an upstream ticket for this (or know of a reason for that script not being present in ROS 2/colcon/ament packages) ? It would be a valuable addition

What's the practical difference between setup.sh and env.sh files in an installed workspace?

IIRC The setup.sh contains all the logic for the environment setup (and is meant to be sourced) and has lasting effect on the current environment, the other is a script sourcing the former and executing the command passed as an argument (does not have lasting effect, setup the env only for the one command.
The following are equivalent:

. <PATH_TO_INSTALL_SPACE>/setup.sh && my_command
<PATH_TO_INSTALL_SPACE>/env.sh my_command

These are not:

. <PATH_TO_INSTALL_SPACE>/setup.sh && my_command && my_other_ros_command
<PATH_TO_INSTALL_SPACE>/env.sh my_command && my_other_ros_command

would prefer, if you would name differently..
https://github.com/ros-industrial/industrial_ci/blob/master/industrial_ci/src/util.sh#L49
(In our case, it chooses the right workspace in the chained order)

haha I see. Thinking about it more, there is little value in providing such an alias and educating people to use the scripts present in the install space is a better way to go. As said above it also "states clearly which environment is used" instead of hiding it from users.

[Rayman]

I've always just prefixed commands in containers with /opt/ros/$ROS_DISTRO/env.sh, which seems to take care of all of this.

Nice, that's a really clean way

[ruffsl]

Looks like we're in agreement that the install scripts should be used to setup the environment within the RUN directive, and that dockerfiles shouldn't hardcode the ROS_PYTHON_VERSION evn itself. With the update to the library repo documentation, I think we could close this.

[Rayman]

Yes, thanks for the discussion