"Hashmaps" are not evaluated properly?

[RaitoBezarius]

It seems like that hashmaps constraints [pattern]: value are not enforced, I don't know if this is a current bug or a not-done-yet feature.

What version of CUE are you using (cue version)?

$ cue version
cue version 0.4.3 linux/amd64

Does this issue reproduce with the latest stable release?

Yes.

What did you do?

#BootspecV1: {
	system:         string
	init:           string
	initrd?:        string
	initrdSecrets?: string
	kernel:         string
	kernelParams: [...string]
	label:    string
	toplevel: string
}

// A restricted document does not allow any official specialisation
// information in it to avoid "recursive specialisations".
#RestrictedDocument: {
	"org.nixos.bootspec.v1": #BootspecV1
	[=~"^"]:                 #BootspecExtension
}

// Specialisations are a hashmap of strings
#BootspecSpecialisationV1: [string]: #RestrictedDocument

// Bootspec extensions are defined by the extension author.
#BootspecExtension: {...}

// A "full" document allows official specialisation information
// in the top-level with a reserved namespaced key.
Document: #RestrictedDocument & {
	"org.nixos.specialisation.v1"?: #BootspecSpecialisationV1
}

What did you expect to see?

$ cue eval file.cue
#BootspecV1: {
    system: string
    init:   string
    kernel: string
    kernelParams: []
    label:    string
    toplevel: string
}
#RestrictedDocument: {
    "org.nixos.bootspec.v1": {
        system: string
        init:   string
        kernel: string
        kernelParams: []
        label:    string
        toplevel: string
    }
}
#BootspecSpecialisationV1: [string]: #RestrictedDocument
#BootspecExtension: {}
Document: {
    "org.nixos.bootspec.v1": {
        system: string
        init:   string
        kernel: string
        kernelParams: []
        label:    string
        toplevel: string
    }
}

What did you see instead?

#BootspecV1: {
    system: string
    init:   string
    kernel: string
    kernelParams: []
    label:    string
    toplevel: string
}
#RestrictedDocument: {
    "org.nixos.bootspec.v1": {
        system: string
        init:   string
        kernel: string
        kernelParams: []
        label:    string
        toplevel: string
    }
}
#BootspecSpecialisationV1: {} /// <-- this is wrong and does not enforce anything.
#BootspecExtension: {}
Document: {
    "org.nixos.bootspec.v1": {
        system: string
        init:   string
        kernel: string
        kernelParams: []
        label:    string
        toplevel: string
    }
}

[verdverm]

What command are you running? (there are some guidelines here for creating reproducers: https://github.com/cue-lang/cue/wiki/Creating-test-or-performance-reproducers)

It looks enforced to me: https://cuelang.org/play/?id=gfsCb0vmY2h#cue@def@cue

I suspect you are using a cue cmd which evaluates and prints the data in an intermediate form and are not seeing what is actually there.

[RaitoBezarius]

I am sorry, I made a mistake in the original post.

It is supposed to be:

#BootspecSpecialisationV1: [string]: #ReservedDocument

I will now edit the original post.

here.

What command are you running? (there are some guidelines here for creating reproducers: https://github.com/cue-lang/cue/wiki/Creating-test-or-performance-reproducers)

It looks enforced to me: https://cuelang.org/play/?id=gfsCb0vmY2h#cue@def@cue

I suspect you are using a cue cmd which evaluates and prints the data in an intermediate form and are not seeing what is actually there.

I used cue eval <file>.cue and I tried to validate:

{"org.nixos.bootspec.v1": { "init": "a", "kernel": "b", "label": "c", "system": "d", "toplevel": "e" }, "org.nixos.bootspec.specialisation.v1": { "work": {}}}

which should be rejected because it's an empty hashmap.

[verdverm]

#BootspecSpecialisationV1: [string]: #ReservedDocument does not require there to be any content, it constrains content should the user provide any. You need to tell CUE that content is required with something like struct.MinFields(1) on that definition.

[RaitoBezarius]

#BootspecSpecialisationV1: [string]: #ReservedDocument does not require there to be any content, it constrains content should the user provide any. You need to tell CUE that content is required with something like struct.MinFields(1) on that definition.

I switched to:

import "struct"

#BootspecV1: {
	system:         string
	init:           string
	initrd?:        string
	initrdSecrets?: string
	kernel:         string
	kernelParams: [...string]
	label:    string
	toplevel: string
}

// A restricted document does not allow any official specialisation
// information in it to avoid "recursive specialisations".
#RestrictedDocument: {
	"org.nixos.bootspec.v1": #BootspecV1
	[=~"^"]:                 #BootspecExtension
}

// Specialisations are a hashmap of strings
#BootspecSpecialisationV1: [string]: struct.MinFields(1) & #RestrictedDocument

// Bootspec extensions are defined by the extension author.
#BootspecExtension: {...}

// A "full" document allows official specialisation information
// in the top-level with a reserved namespaced key.
Document: #RestrictedDocument & {
	"org.nixos.specialisation.v1"?: #BootspecSpecialisationV1
}

And it didn't change that the example JSON I provided is not rejected, I think?
Also, can I choose a preferred field to forcibly exist rather than "there must be at least one"?

[verdverm]

I think there is an understanding gap here. The following is expected output, but does not mean that the constraints are not enforced. You can see this by providing invalid input

I would recommend using cue def and cue export rather than eval. Eval is an awkward middle ground between the other two that can lead to confusion

#BootspecSpecialisationV1: {} /// <-- this is wrong and does not enforce anything.

I also think you may have an extra level of nesting that is not actually needed or wanted, if I understand the data shape you want.

[RaitoBezarius]

I think there is an understanding gap here. The following is expected output, but does not mean that the constraints are not enforced. You can see this by providing invalid input

Thank you for your patience, I am sorry if I am having trouble expressing myself, but I tried to provide invalid input:
{"org.nixos.bootspec.v1": { "init": "a", "kernel": "b", "label": "c", "system": "d", "toplevel": "e" }, "org.nixos.bootspec.specialisation.v1": { "work": {}}}

The work field is empty, ran cue vet invalid.json schema.cue -d 'Document' on it and it did not reject the invalid input. I tried to add strict, concrete and verbose with no avail.

Therefore, I don't think the constraints are enforced.

I would recommend using cue def and cue export rather than eval. Eval is an awkward middle ground between the other two that can lead to confusion

#BootspecSpecialisationV1: {} /// <-- this is wrong and does not enforce anything.

Understood.

[verdverm]

There are a number of inconsistencies between the various examples you have provided.

A complete, working reproducer would be helpful

[RaitoBezarius]

Schema

import "struct"

#BootspecV1: {
	system:         string
	init:           string
	initrd?:        string
	initrdSecrets?: string
	kernel:         string
	kernelParams: [...string]
	label:    string
	toplevel: string
}

// A restricted document does not allow any official specialisation
// information in it to avoid "recursive specialisations".
#RestrictedDocument: {
	"org.nixos.bootspec.v1": #BootspecV1
	[=~"^"]:                 #BootspecExtension
}

// Specialisations are a hashmap of strings
#BootspecSpecialisationV1: [string]: struct.MinFields(1) & #RestrictedDocument

// Bootspec extensions are defined by the extension author.
#BootspecExtension: {...}

// A "full" document allows official specialisation information
// in the top-level with a reserved namespaced key.
Document: #RestrictedDocument & {
	"org.nixos.specialisation.v1"?: #BootspecSpecialisationV1
}

Invalid input which is considered as valid

{
  "org.nixos.bootspec.v1": {
    "init": "a",
    "kernel": "b",
    "label": "c",
    "system": "d",
    "toplevel": "e"
  },
  "org.nixos.bootspec.specialisation.v1": {
    "work": {}
  }
}

Reproducer invocation

$ cue vet invalid.json schema.cue -d 'Document'

[verdverm]

cue def is your friend, it will show you more of the structure: https://cuelang.org/play/?id=glUCheCIw0H#cue@def@cue

You still have typos in your example, those top level Document fields do not match

[RaitoBezarius]

cue def is your friend, it will show you more of the structure: https://cuelang.org/play/?id=glUCheCIw0H#cue@def@cue

You still have typos in your example, those top level Document fields do not match

Thank you so much, I am sorry for making you waste your time!