We are looking into adding features to snapd to be able to unset config options of snaps. It’s been often pointed rightly as a wart that this has been missing so far.
Given that config options have always been intended to provide a user-friendly mechanism through snap set/get commands and not only for programmatic/machine use, it was not intended nor should it be necessary or good design, to use JSON null values as config option values, or to distinguish them from the unset state of an option. But so far snapd has let them through and allowed setting options to null.
Internally snapd in most situations considers setting something to nil/null to mean a request to unset, this hasn’t been the case for options so far, but it would be the relatively natural way to request that at the API level.
We would like to correct the current confusion around null values and options, and to enable such a design. We need to decide how to behave in the face of null values going forward, these are potentially backward incompatible changes but over corner cases and/or not quite good usage of the current features as intended. We are considering the following options:
- have a phase over which snapd errors if
snap setor the underlying API respectively is presented with JSONnullvalues - have a phase over which already
snap setor API usages withdotted.keys=nullmeans unsetting, while JSONnullvalues nested deeper in option values are normalized away/ignored.
Given the previous considerations 2. would seem a better compromise over breaking existing code vs raising awareness that change are coming than 1. . After changes in 2. have settled we would introduce explicit commands to unset options.
We would like to hear concerns about existing snaps that would be affected, or general feedback on the plan. Of course these initial changes would be introduced over a release cycle of snapd (later than 2.40 at this point) first in edge, beta then candidate before going to stable.