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

Implement a constraint parser for more complex inputs #223

Open
tegefaulkes opened this issue Jul 5, 2024 · 6 comments
Open

Implement a constraint parser for more complex inputs #223

tegefaulkes opened this issue Jul 5, 2024 · 6 comments
Labels
development Standard development

Comments

@tegefaulkes
Copy link
Contributor

tegefaulkes commented Jul 5, 2024

Specification

I'm re-opening this. We want to explore using a Constraint parser for parsing the vaults secret path. This should also allow for escaping certain characters we'd otherwise disallow such as =. For example, vault:this/secret\=name\==value should be valid. vault:this/secret\=name==value would be invalid for having two un-escaped = and vault:this/secret\=name\==value= for having an invalid = in the value section.

That said, for the usage of secret env command, an = inside the secret name would be invalid since it would be an invalid environment variable name. Directory paths should be able to include = however.

Right now I'm pegging this expansion to the logic as a low priority. It's a lot of extra work just to allow = in the secret directory names.

On top of this, I think the error for failing to parse the vault secret path could be clearer and conditional. For example, if it failed to parse due to an invalid character, the exact reason needs to be defined.

Additional context

Related #199

Tasks

  1. Further spec out a constraint parser for more complex parsing of inputs and options.
  2. Apply this constraint parser to parsing secrets paths.
@tegefaulkes tegefaulkes added the development Standard development label Jul 5, 2024
Copy link

linear bot commented Jul 5, 2024

@CMCDragonkai
Copy link
Member

I think your backtick formatting needs a bit of a fix above.

@CMCDragonkai
Copy link
Member

This is not that difficult. Use chatgpt and write out a LL1 parser. If we need backtracking, peg parsing works too. This is actually comp sci 101.

@CMCDragonkai
Copy link
Member

@aryanjassal

@CMCDragonkai
Copy link
Member

Backtracking parsers allow one to write simpler grammars that retain a sort of ambiguity. The resulting grammar is more compact by leveraging ambiguity that's resolved by pattern matches or semantic predicates.

I'm following parsing combinators in my design of the parser utilities.

https://chatgpt.com/share/e/065e9f3d-4bc4-4d5e-9ec4-e95ab864e9a9

They are meant to be simple and easily human debuggable compared to peg or ll(K). If we ever need more sophisticated then peg. However this problem is too simple. It should be solvable with parsing combinators like we are currently doing.

@CMCDragonkai
Copy link
Member

If the problem here can be more well specified with clear examples, I can feed it into ChatGPT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Standard development
Development

No branches or pull requests

2 participants