std.sort differs from go-jsonnet implementation

[Josh]

When running kubecfg and jsonnet on the same definitions, jsonnet fails whilst kubecfg passes without issue.

Should differences like this be cleared up so that both tools can be used on the same sources?

Reproducing

jsonnet version 0.15 from https://github.com/google/go-jsonnet
kubecfg version v0.16.0

• kubecfg show file.jsonnet
• jsonnet file.jsonnet

# file.jsonnet
{
  apiVersion: 'v1',
  kind: 'List',
  items: std.sort([
    {
      apiVersion: 'v1',
      kind: 'Namespace',
      name: 'test',
    },
    {
      apiVersion: 'v1',
      kind: 'Namespace',
      name: 'test2',
    }
  ])
}

[Steven E. Harris]

jsonnet fails because the lone argument passed to std.sort is invalid for use with the default key function; you need to pass a second argument with a key function that can compare two objects.

It's not clear to me how kubecfg could sidestep the invalid call to std.sort there. That is indeed strange. @sbarzowski, you may be able to comment here.

[Stanisław Barzowski]

Yeah, Jsonnet, by design, does not provide a default way to sort objects. You need to specify how you want them to be sorted with keyF.

For example you can sort by name as follows:

std.sort([
    {
      apiVersion: 'v1',
      kind: 'Namespace',
      name: 'test',
    },
    {
      apiVersion: 'v1',
      kind: 'Namespace',
      name: 'test2',
    }
  ], keyF=function(obj) obj.name)

I have no idea how kubecfg does it. I briefly looked at the vendored code and I didn't notice any modifications to default comparison or the sort. I didn't notice it overwriting any part of std. Perhaps someone more familiar with kubecfg could tell what's going on.

[Stanisław Barzowski]

I performed some experiments and I was able to confirm that kubecfg shows the file. It doesn't seem to actually sort the objects – in all examples I tried, the original order was preserved.

[Steven E. Harris]

Vaguely related, but maybe not at all: #289 (comment).

I know that kubecfg resorts objects in some cases. It also has special handling for v1/List objects. However, I don't see how it would ever even see such an object here without running into the evaluation failure first.