Writing a field twice

A bucket module declares encrypted with a default of true. A caller sets it to false while debugging an upload failure. OpenTofu uses the caller's value.

module "logs" {
  source    = "../../modules/bucket"
  name      = "logs"
  encrypted = false
}

// estate.cue
buckets: logs: encrypted: true
// team.cue
buckets: logs: encrypted: false

The module declares variable "encrypted" { default = true }, and the caller's line replaces it. The same rule appears across HCL.

• merge({ encrypted = true }, { encrypted = false }) returns a map in which encrypted is false.
• A variable that is set in terraform.tfvars and again with -var takes the value of the last source.
• A validation block can refuse false, but only when the module author wrote one.

In HCL the last writer wins. CUE has no last writer. A field is a constraint, and writing it twice adds a second constraint. The value must satisfy both. That is unification. When no value can satisfy both, you have a conflict, and pravo stops. You caused one in Start, step 8. This lesson shows why it happens.

The widget below applies the rule to a type and a range. Pick a value to write against them. The four programs under it are the ones that pravo eval ran for this page.

package main

size: int & >=1 & <=10
size: 3

size: 3

package main

size: int & >=1 & <=10
size: 0

Error: evaluating .:
size: invalid value 0 (out of bound >=1):
    ./main.cue:3:13
    ./main.cue:4:7

package main

size: int & >=1 & <=10
size: 11

Error: evaluating .:
size: invalid value 11 (out of bound <=10):
    ./main.cue:3:19
    ./main.cue:4:7

package main

size: int & >=1 & <=10
size: "3"

Error: evaluating .:
size: conflicting values int and "3" (mismatched types int and string):
    ./main.cue:3:7
    ./main.cue:4:7

Copies that agree

Work in the directory from A2. If you start here, write this file.

package estate

buckets: {
	logs: {
		name:           "logs"
		versioning:     true // keep old versions
		encrypted:      true
		retention_days: 365
		tags: owner: "platform"
	}
	uploads: {
		name:           "uploads"
		versioning:     false
		encrypted:      true
		retention_days: 30
		tags: owner: "web"
	}
}

rules: {
	https: {
		port:     443
		protocol: "tcp"
	}
	ssh: {
		port:     22
		protocol: "tcp"
	}
}

A second file can say more about the same fields. Both files start with package estate, so pravo reads them as one specification. A4 explains how. Write team.cue.

package estate

// The same value, said again.
buckets: logs: encrypted: true

// A bound that the value already meets.
buckets: logs: retention_days: >=90

// A new field in a struct that already exists.
buckets: logs: tags: cost_center: "4711"

Ask for the logs bucket.

name:           "logs"
versioning:     true
encrypted:      true
retention_days: 365
tags: {
	cost_center: "4711"
	owner:       "platform"
}

Each pair of copies became one value.

• encrypted appears twice with the same value. The result is that value.
• retention_days is 365 in one file and >=90 in the other. The value meets the bound, so the result is 365.
• tags is a struct in one file and a struct in the other. The result is one struct with the fields of both.

In each case the result is the more specific copy, or the details of both. Nothing was replaced.

3
3

A copy that disagrees

Someone debugs an upload failure and adds one line to team.cue. Replace the file.

package estate

// Added while debugging uploads.
buckets: logs: encrypted: false

Error: evaluating .:
buckets.logs.encrypted: conflicting values false and true:
    ./estate.cue:7:19
    ./team.cue:4:27

In HCL, the same two statements give a plan that uses the caller's value. In CUE they give no plan until someone decides which line is wrong.

Read the error from left to right.

• Stage. evaluating says that both files are valid CUE and that their values do not unify.
• Path. buckets.logs.encrypted is the field in dispute.
• Values. false and true are the two values that cannot both hold. The message does not say which came from where. Open both locations.
• Locations. Each file:line:column points at one side. Line 7 of estate.cue holds true. Line 4 of team.cue holds false. The column is the start of the value.

pravo stops at evaluation and prints no data. It reports one conflict at a time: fix this one and run the command again to see the next. Reading a CUE error lists the messages you meet.

Every pair of copies falls into one of these rows.

To let a caller change a value, mark the value as a default. That is A6. A plain value is a rule.

Predict

Write the four pairs below into a scratch directory. Each pair is one field written twice.

package predict

a: 3
a: 3

b: int
b: 3

c: owner: "web"
c: stage: "prod"

d: 3
d: "3"

Error: evaluating ./predict:
d: conflicting values 3 and "3" (mismatched types int and string):
    ./predict/p.cue:12:4
    ./predict/p.cue:13:4

package predict

a: 3
a: 3

b: int
b: 3

c: owner: "web"
c: stage: "prod"

a: 3
b: 3
c: {
	owner: "web"
	stage: "prod"
}

Exercise

package estate

// Added while debugging uploads.
buckets: logs: encrypted: false

want() { [ "$(pravo eval -e "$1" 2>/dev/null)" = "$2" ] || { echo "$1 should be $2"; exit 1; }; }
want buckets.logs.encrypted true
want buckets.uploads.tags.owner '"web"'
want buckets.uploads.tags.cost_center '"4711"'
want buckets.uploads.tags.env '"prod"'
echo ok

buckets.logs.encrypted should be true

package estate

buckets: uploads: tags: cost_center: "4711"

buckets: uploads: tags: env: "prod"

Recap

• Writing a field twice adds a second constraint. The value must satisfy both, so the result is the more specific copy or the details of both.
• Two concrete values that differ are a conflict. pravo stops, prints the path, the values and both locations, and reports no data.
• HCL replaces an earlier value with a later one. CUE never replaces. A value that may change is a default, which A6 introduces.

The next lesson shows that the order of lines and files does not matter.