Catkin-tools plugin does not support several keywords with core20

snapcraft
1

I was using the catkin-tools plugin with core18 so far. Since I need Python 3 support in ROS, I thought the easiest solution might be to switch to core20, which uses noetic as default distribution. In the documentation it seems like some of the properties have changed: https://snapcraft.io/docs/catkin-tools-plugin

In fact, catkin-cmake-args was renamed to catkin-tools-cmake-args and catkin-packages to catkin-tools-packages, if I interpret this correctly. However, rosinstall-files and recursive-rosinstall still give me an error:

Failed to load plugin: properties failed to load for workspace: Additional properties are not allowed ('rosinstall-files' was unexpected)

Furthermore, I’m not sure if I missed some changes with ROS noetic:

For core20, this plugin is designed to work with the ROS 1 Noetic Extension. If not using this extension, it is required to set the ROS_DISTRO environment variable to noetic using build-environment .

Why do I need this extension now and not with melodic in core18, @cjp256 ? Do I even need it? And why is it required to set the ROS_DISTRO env variable if I’m not using the extension?

2

If you use the extension, Snapcraft will drive the correct build and runtime environment. If you want to customize that, don’t use the extension.

Prior to core20, the plugins would hackishly affect the runtime environment which we stopped doing in core20. Essentially, we want the core20+ plugins to focus on the build constructs. The extension can dictate the platform (in this case the ros distro) and any related runtime requirements that are per-app.

You are correct with the catkin-tools-* variables. Each plugin property in core20 is prefixed with the associated plugin name.

As far as rosinstall, those have not been implemented for core20, but @kyrofa or @artivis can give you more information on whether it will be supported at some point, or how to do the equivalent.

3

Hi there,

concerning rosinstall, I don’t want to speak for @kyrofa but I’d say it is simply a missing feature that we have to port as well.

4

Ok, I understand. I’m going to use the plugin with the extension then.

For rosinstall, this was a really important feature for me. What would be a workaround if I need to checkout specific branches for a lot of repos?

I’m thinking about using override-pull and calling wstool manually instead…

5

Noetic is using vcstool now instead of wstool, but yeah I’d start with an override-pull and go from there. @artivis is correct, this simply needs to be ported. We had to rewrite the plugins due to snapcraft changing how it did those things in core20 (e.g. the extension stuff), and we wanted to get an MVP out there ASAP as opposed to holding it back until every feature had been ported over. Can you report back and confirm if an override-pull unblocks you?

1 Like
7

I added the override-pull using wstool for now. I will switch to vcstool later. Seems to work.

I realized that the catkin-tools plugin is not setting the ROS_PYTHON_VERSION environment variable. I need to set it since I have several dependencies in my package.xml which depend on the Python version. I tried to add the variable to the catkin-tools part, but it doesn’t show any effect:

build-environment:
  - ROS_PYTHON_VERSION: "3"

What am I doing wrong and shouldn’t this variable be set automatically?

Another issue I’m facing after switching to base: core20 is that the command for my daemon is not executable anymore:

Failed to generate snap metadata: The specified command ‘run-daemon wayland-launch roslaunch nav_launch nav_gui.launch’ defined in the app ‘daemon’ is not executable.

I tried

command: run-daemon wayland-launch roslaunch nav_launch nav_gui.launch

and

command: run-daemon wayland-launch opt/ros/noetic/bin/roslaunch nav_launch nav_gui.launch

I’m using mir-kiosk-snap-launch here, which just got an update, but I’m still using the previous version. Not sure if my issue is caused by the update to core20 base, the new catkin-tools plugin with the extension or the mir-kiosk-snap. Did paths somehow change? @alan_g, the mir-kiosk-snap-launch should work all the same with core20, right?

8

Hi @prex, I don’t think this is related to the mir-kiosk-snap-launch changes.

When changing our snaps to base: core20 I’ve had to change the command: strings to specify paths relative to $SNAP, that seems to be a snapcraft change for core20.

Here’s an example: MirServer/mir-kiosk-scummvm#6

2 Likes
9

Core20 snaps no longer attempts to find the executable. There was a bug that was just fixed (in the edge channel) where Snapcraft would give you this misleading error when it couldn’t find the command at the specified path. Make sure run-daemon is at the root of the snap, or adjust it to be relative to $SNAP as @alan_g suggests.

1 Like
11

I deleted my previous post for a better overview since I figured it out. I couldn’t make it work using the following:

command: bin/run-daemon bin/wayland-launch opt/ros/noetic/bin/roslaunch nav_launch nav_gui.launch
extensions: [ros1-noetic]
...

But then I switched to the command-chain, and it works fine now:

  daemon:
    command-chain:
      - bin/run-daemon
      - bin/wayland-launch
    command: opt/ros/noetic/bin/roslaunch nav_launch nav_gui.launch
    extensions: [ros1-noetic]
    daemon: simple
    restart-condition: always
    refresh-mode: endure 
    ...

My remaining questions are:

  1. I still can’t properly set my environment variable ROS_PYTHON_VERSION with
build-environment:
  - ROS_PYTHON_VERSION: "3"

Any ideas?

  1. Not so relevant since I can just create one .launch file: But is it possible to run several daemons starting a .launch file at the same time? I’m getting a lot of errors like new node registered with same name for standard ROS nodes. Therefore, I’m assuming this is not the idea of it.
12

You’re needing that set at runtime? Try using the environment key on the app itself instead of the part:

apps:
  appname:
    command: ...
    # ...
    environment:
      ROS_PYTHON_VERSION: "3"
13

No, I need it before rosdep is resolving the dependencies in package.xml. We added cases for Python 2 and 3 as described here under 3. :

http://wiki.ros.org/noetic/Migration

However, rosdep in snapcraft is always trying to install both packages.