Configuration options vs null values vs unsetting

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:

  1. have a phase over which snapd errors if snap set or the underlying API respectively is presented with JSON null values
  2. have a phase over which already snap set or API usages with dotted.keys=null means unsetting, while JSON null values 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.