snapcraft 2.27 cannot auto-infer command or library paths

[Joseph Wakeling]

As of snapcraft 2.27, a typical app definition like the following:

   apps:
     dub:
       command: dub

... will fail for classic snaps, because the command wrapper script no longer touches any environment variables (such as adding paths inside the snap to PATH). Instead, it is necessary to specify the full path of the command relative to the base directory of the snap (e.g. `bin/dub` in the case of the above example).

Ideally this should not be necessary: snapcraft knows what it's built and should be able to infer which command is being referred to, and it would be nice if it could auto-detect that `appname` means `$(SNAP)/bin/appname` (or similar).

[Mark Shuttleworth (sabdfl)]

Hmm... I think it might be better to be less magic here.

I would suggest going the other way, and having the 'snapcraft init'
skeleton yaml guide people to the correct outcome. For example, if the
skeleton yaml looked like this:

name: my-snap-name # you will need to 'snapcraft register <my-snap-name>'
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line 79-character elevator pitch for your amazing snap
description: |
  This is my-snap's description. You have a paragraph or two to tell the
  most important story about your snap. Keep it under 100 words though,
  we live in tweetspace and your description wants to look good in the snap
  store.

grade: devel # for edge/beta, becomes 'stable' for candidate/stable channels
confinement: classic # use 'devel' then 'strict' once you have plugs and
slots

#environment: # set env for all apps
# FOO: value
# BAR: value

#apps:
# my-app: # will be exported as snap.app in /snap/bin/
# command: path/to/binary # relative to root of $SNAP
# environment: # specific to this app
# BAZ: value
# my-daemon: # will start automatically
# daemon: simple # see http://snapcraft.io/docs/daemons/
# command: bin/daemon # again relative to root of snap

parts:
  my-part:
    # See 'snapcraft plugins'
    plugin: nil

[Joseph Wakeling (webdrake)]

Yes, fair point. Any kind of auto-inferring is going to risk being fragile. Clear and straightforward guidance is probably a much more robust solution.

I suppose that what I'm really looking for is some protection against the situation I encountered where the autogenerated command wrapper does not invoke anything inside the actual snap (see: https://lists.ubuntu.com/archives/snapcraft/2017-February/003301.html). Would that be a more reasonable 'magic' (i.e. you're expected to get the command path right, but snapcraft can detect if you got it wrong)?

[Mark Shuttleworth (sabdfl)]

Yes, magic is OK if it's limited to offering good guidance.

So if you say:

apps:
  foo:
    command: <something>

Then snapcraft could fail with a helpful error, like:

App 'foo' specifies non-existent command executable. Perhaps try:
    command: path/to/samename/executable ?

[Joseph Wakeling (webdrake)]

> Then snapcraft could fail with a helpful error, like:
>
> App 'foo' specifies non-existent command executable. Perhaps try:
> command: path/to/samename/executable ?

Sounds perfect! Consider my feature request updated accordingly :-)