Hello. We are currently trying to adapt our ROS-based robot to use Snappy Core. Since ROS is highly componentized, we publish around 20 different ROS services from our snap, which have ordering and dependency requirements. We also use .target files to group services.
New Directives that we need include:
Before=, After= For ordering, as mentioned in the OP.
WantedBy=, Wants=, RequiredBy=, Requires=, PartOf=, BindsTo=
These specify dependencies between service and, especially between targets and services. PartOf= enables the services that are started by a target to also be stopped if that target is stopped. BindsTo= allows us to start & stop the ROS service that interfaces with a hardware device whenever the hardware appears or disappears.
We use this to enter to start a different set of services if we have not yet been configured. For example, don’t start our main application node yet but do start a service to download configuration information from the cloud. Although this is the only Condition… directive that we currently use, I can imagine that most of the others are equally useful.
Some behavior in ROS launch files can only be configured using environment variables. Note that the current ability to specify an environment variable in snapcraft.yaml only accepts hard-coded values as far as I know. We need to load them from a config file.
This is helpful for systemd target-based mode switching, in cases where modes are mutually exclusive. For example, higher-energy ROS services would Conflicts= with our low-power.target, and our “normal.target” will Conflict= with our low-power.target
We use this for debugging, by specifying all dependencies via an aliased service name. Thus we can disable the normal service and enable a different one with the same alias to make a substitute. The substitute may compiled with debug flags and no optimization, or run under gdb, strace, etc.
As you can imagine, lack of support for these made porting to Snap a very big challenge. So far, we have to run a configure hook that rewrites the .service files, which is very messy and totally breaks confinement. Supporting these directives in snapcraft + snapd will be a HUGE plus!