juju-core; default configuration value of ""

[William Reade]

David, your bug is definitely real, and the fix for it is just waiting for
a final review. Sorry, and thanks for catching it.

James, yours is more involved. We had originally considered empty string
values to be "impossible" on the basis that, whether set via key=value or
--config with a YAML file, they were interpreted internally as "delete this
key". On this basis, I'm not sure we even explicitly tested for an empty
string default...but we let it through, and now it's a feature.

And, ofc, it's clear that it's not reasonable for us to snatch this feature
away suddenly. So we'll gladly fix it now; but this leaves us in a slightly
uncomfortable position, in which there's a value that's only settable as a
default, and that feels like a misfeature at best. So, long term, we could
deprecate *all* uses of ""; or we could try to find some way to make it UI-
and API-settable; or, possibly, we could grandfather it in as a permanent
exception.

I'm not very keen on the second option, because I think that
`""-means-delete` is a simple rule that everybody already understands at
the UI level, and I'm not keen to introduce special syntax to the CLI to
allow specification of two different sorts of empty strings (one of which
means delete); if there's overwhelming support for it we can of course
accommodate that, but probably not on a helpful timescale.

So, right now, we can temporarily fix and deprecate, or permanently
grandfather it in. The only difference today is whether or not we print a
deprecation warning when we encounter it; but it's informed by the bigger
question of whether we ultimately want to exclude "", or to integrate it
properly.

(FWIW, independent of convenience at the code level, I think there's a real
case to be made that the "language" defined by a config file should be as
high-level and human-focused as possible; an interface that doesn't require
that end-users understand the distinction between null and an empty string
would STM to win, in general, over one that does. Hence, my personal
preference is currently for deprecation.)

Cheers
William

PS in case it's unclear: we're fixing it now, regardless, and we won't
block that on the outcome of this discussion.


On Fri, Jun 21, 2013 at 8:38 PM, Stuart Bishop
<stuart.bishop at canonical.com>wrote:

> On Sat, Jun 22, 2013 at 12:56 AM, James Page <james.page at ubuntu.com>
> wrote:
>
> > A couple of days ago I noticed a change in behaviour for default string
> > configuration values of "" in juju-core when compared to pyjuju.
> >
> > Example config:
> >
> > options:
> >   database:
> >     default: ""
> >     type: string
> >     description: empty string
> >   test_two:
> >     type: string
> >     description: no default string
> >
> > Under pyjuju:
> >
> > config-get --format=json database
> > ""
> > config-get --format=json test_two
> > null
> >
> > Under juju-core:
> >
> > config-get --format=json database
> > null
> > config-get --format=json test_two
> > null
> >
> > Specifically this breaks the postgresql charm on juju-core; I've raised a
> > bug (see [0]) to which the juju-core team have responded; I prefer the
> > proposed new behaviour (its in effect what I do in the charmn helpers I
> have
> > written) but I appreciate that this will probably have impact on a large
> > number of charms; so I'd like to throw this open to the list for further
> > discussion.
> >
> > Thoughts?
>
> (after reading bug comments too)
>
> It would be possible to set null via the command line if relation-set
> accepted json or yaml. We could even get real structured data in there
> instead of all this v.split() rubbish and pickles being shuffled
> around.
>
> I suspect the charms that are complex enough to worry about null vs ''
> are going to need updating for gojuju in any case.
>
> If you are breaking compatibility, you might consider something like
> "relation-set key=val -key2 key3=", where key2 ends up with null and
> key3 ends up with the empty string. If '' and null are pretty much
> interchangable with pyjuju it might not be as invasive as it looks.
>
> --
> Stuart Bishop <stuart.bishop at canonical.com>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130622/c7d2968f/attachment.html>