If you try to define a rule with the assignment operator you get a confusing error message:
package x
p := 1
rego_parse_error: rule name conflicts with built-in function
This is likely because the parsed AST is something like...
package x
assign(p, 1)
We should special-case the error handling to report something more actionable, for example:
rego_parse_error: unexpected := operator (did you mean <rule-name> = ...?)
Couldn't we allow top-level assignments like that, alternatively?
We could support the := operator at the package level, we just need to be careful about semantics.
Inside of a query:
p := 1
p := 2 # not allowed, redeclaration error at compile-time
Inside of a package:
p := 1
p := 2 # same behaviour?
cc @timothyhinrichs curious what you think. I know this will make @mikol happy.
If we made this change we should probably update the REPL to behave the same way. Today in the REPL using := multiple times will redeclare the rule:
> a := 1
Rule 'a' re-defined in package repl. Type 'show' to see rules.
> show
package repl
a = 1
> a := 2
Rule 'a' re-defined in package repl. Type 'show' to see rules.
> show
package repl
a = 2
Using the REPL behavior in packages would be problematic because of multiple files.
If we made this change we should probably update the REPL to behave the same way.
Seems acceptable. unset is already supported and necessary (albeit less convenient than allowing a rule to be rewritten using :=; but I鈥檇 argue that REPL semantics should match package semantics whenever possible).
Sorry but I'm not sure what's the right way of doing now...
aaa := "hello" will throw rego_parse_error: rule name conflicts with built-in functionaaa = hello seems correctCan you confirm the second one is the right way to define variable outside queries?
Thank you,
@sneko if you're seeing that parse error it's because you are running an old version of OPA. This feature was added in v0.14.0. If you're running an older version of OPA then use =.