Telling snapcraft to skip generating wrapper scripts

snapcraft
1

I would like to have a way for snapcraft to skip generating wrapper scripts. One use-case is that when I already use the snapcraft environment support, another one when using a minimal base snap that does not even ship “/bin/sh” (the wrappers are shell scripts).

I created https://github.com/snapcore/snapcraft/pull/1420 for this (pretty simple). The following naming is suggested by @sergiusens:

apps:
    no-wrapper-app:
        command: app
        app-constraints: [no-environment]
    wrapped-app
        command: app

Feedback welcome

2

Given that wrapper is an implementation detail in snapcraft I wasn’t comfortable exposing no-wrappers or wrappers: legacy as originally proposed given that once we fully get rid of wrappers and move it to env you won’t get wrappers but you will get env.

no-environment seems to be the implementation that would stand the test of time (and not leak implementation details).

3

The idea sounds good, but the syntax proposal feels somewhat confusing. There’s definitely an environment… many environments in fact. So it’s completely unclear what no-environment would mean in this case. Also, the wrappers as I understand it are richer than just the environment. The proposal by @mvo seems to imply that we’d want those gone for real once the flag is used.

It also seems like “wrapper” is not a good term for this idea, so these other suggestions don’t sound great either. The problem with wrapper is that it doesn’t explain properly the multi-purpose idea explained above. In other words, the point is not to wrap… that’s just how we implemented it. The point is to prepare the environment for the application to be run.

Here is a proposal that takes those ideas into account:

apps:
    no-wrapper-app:
        command: app
        adapter: none

For now, this would only accept the values “none”, and “”, with the latter being the default and implying the current behavior. The former disables the wrapping altogether, including the environment. With these two settings, down the road we can evolve to support “environment”, which would adapt only the environment, and some other settings as we learn a bit more about these issues.

How does that sound?

2 Likes
4

@jdstrand This is now working, but the review tools still need to learn that this is okay it seems:

Please check the errors and some hints below:
  - unknown fields for app 'jmes': 'adapter
1 Like
5

In looking at this, snapd doesn’t do anything with ‘adapter’. This is a snapcraft.yaml only syntax. Discussing with @niemeyer on IRC, he agreed that snapcraft should remove ‘adapter’ when generating the snap.yaml. As such, I’ve filed bug 1750658. There is now no need to update the review-tools.

2 Likes
6

I am trying to avoid creating wrapper scripts for one of the commands in the snapcraft.yaml but with out any succes. Here is the snippet from my snapcraft.yaml.

migrate:
      command: usr/bin/migrate run
      adapter: 'none'
      plugs: [home, base]
      environment:
      #   PATH: "$PATH:$SNAP/base:$SNAP/base/bin:$SNAP/base/usr/bin:$SNAP/base/sbin"
      #   PYTHONPATH: "$SNAP/base/lib/python2.7/site-packages"
        ALEMBIC_INI: $SNAP_COMMON/alembic.ini
      #   LD_LIBRARY_PATH: "$LD_LIBRARY_PATH:$SNAP/base/lib:$SNAP/base/usr/lib:$SNAP/base/usr/lib/x86_64-linux-gnu:$SNAP/base/usr/lib/x86_64-linux-gnu"

Irrespective of adapter snapcraft is generating the wrapper for my command with invalid LD_LIBRARY_PATH. Is there a workaround for this?