So I’m using snap key/value pairs to communicate between various modules within my snap.
I just discovered that you MUST have a hooks/configure script otherwise using snap set xxx=yyy will fail.
Given I don’t need a configure script (I ended up creating a one line script) it seems an unnecessary requirement.
To be clear I have one app that sets a key/value pair and a daemon that reads the key/value pair.
Its not a big issue, just an annoyance.
That’s an interesting observation, thanks for reporting. I agree this should probably be fixed (I will raise that with the snapd team).
I think this dates back to the time when configure hook script was the only way of consuming these values by the app (i.e. configure script would read the values with snapctl get ... and rewrite app config etc.).
Now that apps from the snap can query the config directly (as you do) it probably makes sense to lift this requirement.
Ok, a short update after quick internal discussion about it. We may indeed re-consider this when configuration schemas get introduced (a schema will ensure config values are valid/sensible etc.; it’s in our plans and should get implemented in not too distant future).
Thanks again for bringing that up.
thanks for the update.
like I said, more an annoyance than a serious issue.
Agreed, this seems historical and should likely be changed. However, I just want to throw this out real quick in case you don’t know: the configure hook is the only opportunity you have to validate the config before it’s applied. You can take a look at the configuration requested by the user, and if it’s somehow invalid you can exit non-zero. That will prevent the configuration from being saved. Might be worth actually having the hook in a lot of cases.
Good thought on the validation front.
Forcing the existence of configuration hook is intentional and at least so far not something that I’d recommend changing (cc @pstolowski).
Rationale:
It’s a good idea to flag somehow that snaps can make use of configuration. Those that don’t will prevent the user from setting.
Very frequently if the snap has configuration it’s useful to have some action done at change time. In those cases the requirement becomes invisible.
In other cases, having the empty placeholder script solves the problem of flagging the snap as supporting configuration, and makes the snap ready to process configuration further with trivial changes.
In the near future we will also have a richer mechanism to specify configuration schemas, so that validation becomes more strict and more convenient. At that point, we should change the rule to be that the snap needs to either have a configuration hook or a schema.
