Woot, that’s great to know. The up side is that 2.36 ships with layouts enabled and that nested directory limitation lifted now. Please try edge again and see if you can simplify your snapcraft.yaml now. I also heard that snapcraft will support layouts directly (CC @kyrofa to confirm please) so that the passthrough section can go away.
Yessir, but only in edge right now, it’ll be in the next stable release (but only if using bases).
1 Like
I’ve just added this to The snap format document. Thanks!
1 Like
Just wanted to give feedback that layouts have been working fine for me since 2.36 and switching to snapcraft v3 was seamless in that regard. I have had the passthrough wrapper active because I’m using launchpad for ARM builds and when I last checked, those builders didn’t have layouts enabled by default.
One minor hiccup that might be related to layouts: My snap’s install hook performs some tasks in the writable mounted directories. If the hook fails (because I had a thinko or something was missing), any attempt to reinstall a newer, fixed revision of the same snap will throw an error during the install hook that the layout mount at /var/snap/my-snap/current/some/subdir does not exist. Once I reboot, the error goes away and I can install the fixed revision just fine.
@tobias, is your issue similar to the one I encountered here: Snapd 2.37.1 refresh broke layouts snap remove/install ?
It would be interesting to see if you have a similar issue with the mount point showing up with //deleted at the end. You could try logging to $HOME the output of cat /proc/self/mountinfo during the hook.
@ijohnson The snap does not get installed when install fails, so I can’t really look inside the snap. I’ll see if I can throw together a test case that’s triggered on-demand after installation.
Interesting, please file a bug. It seems that on failed install we don’t discard any namespaces we have created.
Nice edits, really appreciated!
I wonder if this feature is compatible with the SNAPCRAFT_ARCH_TRIPLET variable?
Too lazy to verify it myself 
I wonder what’s the usecase of symlink ?
Not everything has to be a bind mount. A symlink is much more lightweight way to relocate something.
2 Likes
One of my snaps that uses layouts suddenly gets rejected on automatic review in the store:
invalid source mount: '$SNAP/api/tmp'(should be a legal path and not start with: /boot, /dev, /home, /lib/firmware, /lib/modules, /lost+found, /media, /proc, /run, /sys, /tmp, /var/lib/snapd, /var/snap lint-snap-v2_layout_target ($SNAP/api/tmp)
As you can see in the snapcraft.yaml source, I’m mapping $SNAP/some/path to $SNAP_DATA/some/path. The application running in $SNAP/api expects everything to exist beneath its root directory, but some of those have to be writable. The previous snap revisions (last one built on 2019-07-04) went through review just fine. I tried with and without the passthrough wrapper, so I presume that the store gained layout linting in the meantime.
Is this expected? What can I do to have my snap pass review again?
It did. I’ll take a look and respond via the store review process.
Ok, as you probably saw, I approved these. The fix is in master and I’ve requested a store pull.
1 Like
Thank you for the fast response + fix + approvals, much appreciated!
Is there a repo/status page where I can see if the fix has been deployed, so that I don’t push revisions until this passes again?
No, but it just got deployed so feel free to upload again 
1 Like
Given that review-tools are a separate public project, it might make sense for the dashboard to display somewhere which revision it is using ATM, probably not interesting for everybody and not super high-prio, but not silly either.