Regression: No difference between "legacy" and "full" app adapter

[Kyle Fazzari]

I was surprised to see that this snapcraft.yaml:

name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core18 # the base snap is the execution environment for this snap
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
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 # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots

apps:
  hello:
    command: hello.sh
    adapter: legacy

parts:
  my-part:
    # See 'snapcraft plugins'
    plugin: nil
    override-build: |
      echo "#!/bin/sh\necho 'hello'" > "$SNAPCRAFT_PART_INSTALL/hello.sh"
      chmod a+x "$SNAPCRAFT_PART_INSTALL/hello.sh"

Produced exactly the same priming area as the same snapcraft.yaml, but using the "full" app adapter instead. They are both what "full" should be: using the command-chain instead of generating wrappers. Not only should they not be the same, but "legacy" is still supposed to be the default, according to the schema. It means that there is no way today to generate a snap that doesn't assume command-chain.

[Sergio Schvezov (sergiusens)]

Don't you recall in Lyon that we decided to make smart decisions on when to use a wrapper and when not to, making the adapter keyword obsolete?

[Kyle Fazzari (kyrofa)]

I don't remember discussing removing the ability for a user to say "please continue making snaps that don't use command-chain." That said, I'm sure at this point the number of snapds out there without support is small. If we remove the meaning of adapter, though, it's probably worth warning if it's set (right now it's just completely ignored).