Over the years it has become a fact of life that a snapped application requires a good chunk of environment variables and in some cases setup code in order to run successfully. Today, the snapcraft CLI satisfies this requirement by generating shell wrappers for defined apps, which have a few problems:
- They are opaque, complex, and confusing to the developer introspecting the snap once built
- They are completely transparent to snapd: it doesn’t know about them. As a result, things like
snap run --shellcan’t take them into account, dropping the developer into an environment that isn’t truly representative of the app.
Snapd supports an
environment keyword for apps (although not hooks, which should probably be changed) that snapcraft could be using for the environment variables it needs to define. However, that doesn’t cover the use-case of having logic that needs to run before the app, such as desktop helpers, ROS setup scripts, etc.
Snapd should grow support for chaining commands together in order to actually run an app or a hook, where the syntax would look like this:
# <snip metadata # For an app apps: my-app: command-chain: [command1, command2] command: my-app-command # For a hook hooks: configure: command-chain: [command1, command2] # <snip parts>
my-app or the
configure hook, it actually ends up running the command chain in order before finally executing the command, e.g.
command1 command2 my-app-command. Additionally, when running
snap run --shell my-app-command, snapd will run the command chain prior to dropping the user into a shell, e.g.
command1 command2 bash.
With this proposal implemented, snapcraft can move away from wrappers completely and start using a combination of the