Changed the build type to ament_python and fixed package to run with ros2 run

[ahcorde]

Fixed package to run with ros2 run rqt_msg rqt_msg. Related to this issue ros-visualization/rqt_console#20

Signed-off-by: ahcorde [email protected]

[ivanpauno]

LGTM with comment addressed and green CI

[ahcorde]

• Linux
• Linux-aarch64
• macOS
• Windows

[hidmic]

Rebased on top of foxy-devel and patched to build. I verified it can be ros2 run on Windows.

Running CI up to rqt_msg, rqt_srv, rqt_service_caller, rqt_top, rqt_shell, rqt_py_console, rqt_publisher, rqt_plot:

• Linux
• Linux-aarch64
• macOS
• Windows

[ivanpauno]

LGTM!

With this will be able to only run ros2 run rqt_msg rqt_msg but not rqt_msg.
That was also the case before, but it isn't the case for other rqt tools like rqt_graph.

[ivanpauno]

Unrelated: Can we add the actual maintainers here?

I'm sure Dirk isn't active, no idea about the others.

[hidmic]

+1, but since we have to update the package.xml too, what about doing it in another PR? I think @mjcarroll is the maintainer now. I'm not sure.

[ivanpauno]

sure we can do it in another PR, it's unrelated to the purpose of this one

[hidmic]

That was also the case before, but it isn't the case for other rqt tools like rqt_graph.

We should sort that out. It's somewhat confusing. I think rqt should be the only top-level binary we put in the PATH. You can access all rqt functionality within the same dashboard.

[clalancette]

We should sort that out. It's somewhat confusing. I think rqt should be the only top-level binary we put in the PATH. You can access all rqt functionality within the same dashboard.

I'm not sure I agree. While running rqt with a single plugin works, it is pretty convenient to just do rqt_graph (or whatever) and have it automatically create a window and populate it with a single plugin.

With this will be able to only run ros2 run rqt_msg rqt_msg but not rqt_msg.
That was also the case before, but it isn't the case for other rqt tools like rqt_graph.

I'm on the fence about this change. First, is it at all technically feasible to have both ros2 run rqt_msg rqt_msg and rqt_msg work? Assuming that is the case, the latter is pretty nice because it is much shorter to type. Given that it is a tool users will almost always be launching by hand (and not through a launch file), that property is pretty important.

[ivanpauno]

I'm on the fence about this change. First, is it at all technically feasible to have both ros2 run rqt_msg rqt_msg and rqt_msg work? Assuming that is the case, the latter is pretty nice because it is much shorter to type. Given that it is a tool users will almost always be launching by hand (and not through a launch file), that property is pretty important.

With ament/ament_cmake#328 in, we could install a console script correctly in both /bin and /<package_name>/lib correctly if the package is ament_cmake.
It's a bit of an overkill to use ament_cmake for pure python packages, but setuptools doesn't allow to install scripts to two folders (you can only specify one).

I can imagine two alternatives for ament_python packages:

• Install the executable in /bin and use data_files to install the .py script in /lib/<package_name>.
  The extension is pretty important 😉 (we could use the same logic in all platforms actually, so the shebang line isn't strictly needed).
• Modify ros2run so it looks for an executable in /bin if it didn't find one in /lib/<package_name>.
  By doing this, we avoid the problem of having to install an executable in two places all together.

The disadvantage of the first option is that installing a non binary file in lib/ is arguably wrong (though I'm not sure if it's actually wrong).

The disadvantage of option two is that "packageA" is not supposed to install packages in "lib/packageB", whereas anybody can install executables in "bin/". So looking for executables in bin/ as a fallback when calling ros2 run <package_name> <executable_name> will kind of ignore the package name (i.e. ros2 run rclcpp rqt_msg will work lol).
As an alternative, we can only apply the fallback when the package name and the executable name are the same.
It's a bit arbitrary, but it works for the cases we want this.

[clalancette]

Looking at rqt_graph, it looks like we are doing the first of your two options; installing the script into lib as part of data_files. I'd suggest doing the same here (and in all of the rqt_*) packages.

[ivanpauno]

Looking at rqt_graph, it looks like we are doing the first of your two options; installing the script into lib as part of data_files. I'd suggest doing the same here (and in all of the rqt_*) packages.

Sounds good to me.
ros2 run rqt_graph rqt_graph is actually not working on Windows, because the installed file doesn't have a .py extension (though that should be easy to fix).

[ivanpauno]

ros2 run rqt_graph rqt_graph is actually not working on Windows, because the installed file doesn't have a .py extension (though that should be easy to fix).

Actually, in that case we will need to run ros2 run rqt_graph rqt_graph.py which isn't ideal (though that could be fixed by modifying ros2run?).
And it's also a problem to import rqt_graph from a file called rqt_graph.py, and not from one called rqt_graph 🤦‍♂️.

Maybe there's another way to detect if a file is a python script without relying on the file extension (?).
I'm not sure what's the right solution here, I've run out of ideas 😃 .

[hidmic]

While running rqt with a single plugin works, it is pretty convenient to just do rqt_graph and have it automatically create a window and populate it with a single plugin.

I will point out that you can do that with rqt -s rqt_graph.ros_graph.RosGraph (see here), which IMHO is better than polluting the PATH. I understand the convenience, but by that same token, why not having aliases for every other tool? I know I could use a few for colcon :)

---

Regardless of the path we take, I'd say we defer that to another set of PRs. Most rqt plugin packages do not do what
rqt_graph does, even the ones for which there's no PR open. Thoughts? @ivanpauno @clalancette

[hidmic]

Alright, as per offline discussion, we'll move forward with these changes as they are now. We'll defer improvements to the Windows situation for later.

[ivanpauno]

I was thinking that another way to install an executable in both bin/ and lib/<package_name>/ is to hack the colcon-ros ament_python build task.

The hack would be something like this:

• Test if a file called <source_directory>/AMENT_PYTHON_COPY_TO_BIN exists.
• If that file exist, each line of that file is an executable path (relative to the install prefix, e.g. lib/<package_name>/<executable_name>).
• Then colcon-ros will copy <executable_path> to <install_prefix>/bin/<executable_name>.

I'm not sure if we are open to re-releasing colcon-ros at this point though, but I can give it a try if we are.