Last week I’ve had a good conversation with @kalikiana about a recurring problem we find: we need to be able to use new features of snapd as soon as they are available, and in fact even before they are available (edge, beta, etc), and we should be able to use snapcraft without it refusing to pass on option that it does not understand.
So here is the proposal we got to:
- Snapcraft will accept two new fields, named “passthrough”. One at the top level, and one at the application scope. In points below, these locations are referred to as the target scope.
- When these fields exist they must necessarily contain a map.
- Options inside the map are passed through directly into “snap.yaml”, in the target scope where the passthrough option itself lives.
- Snapcraft must forbid defining an option inside the passthrough if that option is also directly present in the target scope.
- Snapcraft must warn whenever it sees an option in the passthrough, to remind the publisher that these options are not yet supported, with a message similar to:
“Unsupported options are being passed through into the snap without validation.”
- Snapcraft might learn to report options that are potentially already supported. But it must not prevent these options from being passed through, since the option may be defined in a way that is not yet understood by Snapcraft and should thus pass through.
How does that sound?
FYI, the review tools in the store will continue to prompt for manual review when they see the passed through content, but it sounds like that continues to be exactly what we want (we can always manually approve).
As someone using the “layouts” feature heavily, this does sound like a solution to the annoying problem I’m hitting continually. But I have to ask if it is avoiding the greater problem: why is snapcraft ignorant of features snapd supports?
Could snapcraft have super-basic support for experimental features in snapd, printing a warning whenever the user uses them that they are not validated and liable to change? At least then syntax errors and typos will be reported at creation time and not install time. The feature label could be prefixed to distinguish them from formally supported features, e.g. “experimental-layouts:”, so later snapcrafts can recommend adopting the formal syntax.
I’d just be concerned that snapcraft could fall further behind if people start to rely on this passthrough feature.
You’re describing pretty much what pass-through is about. Except the proposal is a dedicated property that declares those experimental features rather than weakening validation of the entire
snapcraft.yaml. So you would say for example
You can see here both global properties and app-specific properties that exist being overridden by pass-through, and new ones that Snapcraft doesn’t know about. Note that all known properties are still validated normally here and only what’s specified in pass-through is not type-checked.
You will 1) get a warning for using pass-through, telling you that it’s not validated and can’t be released to the store 2) as well as an error if you’re trying to specify values in pass-through that are already regular properties in the same
Implementation here: snapcraft#2053
Per comment there, looks surprisingly clean. The only recommendation looking through the code would be to keep “passthrough” without the hyphen as suggested in the first proposal above.
That’s cleaner in code and avoids underlines and dashes in what is a single term conceptually. Both forms seem to exist in English, with the one without the hyphen usually being used for nouns.
Is there a reason we don’t want this for other top-level objects in the
snap.yaml? Hooks, plugs, slots?
These are not really validated right now as far as I’m aware ie. in the schema they are mere
Ah indeed, plugs and slots are just passed through already. Hooks are limited to a
plugs property, though.
I’ve just started playing with this feature using snapcraft 2.41 from beta channel, it appears that snaps built with
passthrough are gated by snapcraft, I’m getting the following warning:
The 'passthrough' property is being used to propagate experimental properties to snap.yaml that have not been validated. The snap cannot be released to the store.
@sergiusens @kyrofa Can we please remove the second part of this message? What we want to do is to flag for manual review rather than reject it, but it’s the store that should be reporting that not snapcraft itself, since those rules can change and snapcraft won’t know it.
Note that nothing is gated here, it’s just meant to be a warning about the fact that the store will flag it. However, you’re right: the store may add support for whatever is being passed through, it doesn’t make sense for Snapcraft to really say anything about the store.
Second part of the message removed here.