Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

format: Bracketing keyword ref elements in formatter output #7010

Merged

Conversation

johanfylling
Copy link
Contributor

@johanfylling johanfylling commented Sep 10, 2024

Also future-proofing format pkg tests to be 1.0 compatible.

Signed-off-by: Johan Fylling <johan.dev@fylling.se>
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
@@ -0,0 +1,11 @@
package test.contains2 # FIXME: refs aren't allowed to contains keywords
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out, not allowing keywords in refs is an actual issue in v1, and not just a nuisance.

We can make the test.contains package parse by bracketing it: test["contains"].
This is however not only ugly for no actual benefit, but the formatter will actually output it as package test.contains, which won't parse 😞.

We could fix the formatter to output package test["contains"] instead. But I think we should instead allow refs to contain keywords.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think we should instead allow refs to contain keywords.

Was there a reason to not allow refs to contain keywords?

We could fix the formatter to output package test["contains"]

We could update the --rego-v1 flag to do that. But as you said we should allow refs unless there is a good reason not to do it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the argument against allowing keywords in refs is that we don't allow such rule names, e.g.

package foo

if if { true } # error: 'if' is not a valid rule name

but we allow you to create an empty module:

package foo.if

which would generate an empty virtual document at data.foo.if. This creates a sort of parity mismatch, where we allow you to create data.foo.if one way, but not the other.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That can still be created via JSON data, so won't that mismatch always exist? The question is why you wouldn't be allowed to reference such data (without special handling / quoting) where it's impossible for it to clash with a keyword... i.e. input.package is obviously distinctly different from package alone.

Copy link

netlify bot commented Sep 24, 2024

Deploy Preview for openpolicyagent ready!

Name Link
🔨 Latest commit b38ed63
🔍 Latest deploy log https://app.netlify.com/sites/openpolicyagent/deploys/66f51685bdeecc00089637ad
😎 Deploy Preview https://deploy-preview-7010--openpolicyagent.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Signed-off-by: Johan Fylling <johan.dev@fylling.se>
@johanfylling johanfylling changed the title rego-v1: Future-proofing format pkg tests to be 1.0 compatible format: Bracketing keyword ref elements in formatter output Sep 25, 2024
Copy link
Member

@ashutosh-narkar ashutosh-narkar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Few comments 👇

format/format.go Outdated
@@ -1067,7 +1089,8 @@ func (w *writer) writeImports(imports []*ast.Import, comments []*ast.Comment) []
})
for _, i := range group {
w.startLine()
w.write(i.String())
//w.write(i.String())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: remove

Path: ast.MustParseTerm("future.keywords." + kw),
// NOTE: This is a hack to not error on the ref containing a keyword already present in v1.
// A cleaner solution would be to instead allow refs to contain keyword terms.
Path: ast.MustParseTerm("future.keywords[\"" + kw + "\"]"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding an example in the comment would be helpful.

@@ -7,3 +7,7 @@ contains := 2
in := 3

every := 4

p {
data.foo.contains.bar == 42
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this won't be formatted to data.foo["contains"]["bar"] since the foo is not a keyword?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would have been converted to data.foo["contains"].bar, but other parts of this module are triggering errors.

@@ -0,0 +1,13 @@
package test["contains"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change this to package test.contains and the formatter makes it test["contains"]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't do that, as the parser is operating under v1 rules and would reject that package ref.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So package test.contains will be a parser error in v1 but when formatted using --rego-v1 flag, the path will get converted to package test["contains"]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct 👍

@@ -0,0 +1,10 @@
package test["if"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change this to package test.if and the formatter makes it test["if"]

@johanfylling johanfylling merged commit 4ba95d0 into open-policy-agent:main Sep 26, 2024
28 checks passed
@johanfylling johanfylling deleted the rego-v1/update_format_tests branch September 26, 2024 08:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants