caddyfile: Expose Tokenize function for modules to use the lexer #3549
Conversation
francislavoie
force-pushed
the
refactor-lexer
branch
from
8d0580e to
bcb85af
Compare
| // a list of tokens that can be parsed as a Caddyfile. | ||
| // Also takes a filename to fill the token's File as | ||
| // the source of the tokens, which is important to | ||
| // determine relative paths for `import` directives. |
There was a problem hiding this comment.
Add a scary warning that this function is experimental and is not guaranteed to be stable.
There was a problem hiding this comment.
I don't think it's experimental... It's the exact same code that was in parser.go and also in the tests (with I guess very minor differences due to types)
There was a problem hiding this comment.
Whether it's experimental or not, we need to say that it's not stable ("experimental" is a good consistent term) because I wasn't ever expecting to export this API when I designed it.
There was a problem hiding this comment.
I'm not sure I understand how it wouldn't be stable if it's actually used by the Caddyfile parser itself.
There was a problem hiding this comment.
I just mean that right now we can change it whenever we want, because we know it's unexported and nobody else is using it. I just try to avoid exporting things.
There was a problem hiding this comment.
As I mentioned in the other PR, this is not a must-have.
We can give it some time and see how caddy-docker-proxy code will evolve.
And also see if the lexer will change that often in caddy
There was a problem hiding this comment.
@lucaslorentz Is Tokenize() the right function to export? Or do you need env var replacements, I can't remember. If you need env var replacements, maybe allTokens is better: https://github.com/caddyserver/caddy/pull/3549/files#diff-06ecc7b9618d6f991e3d8846d817e0dcR85
There was a problem hiding this comment.
I'm pretty certain we don't want env var replacement to happen because the step that caddy-docker-proxy takes is just rebuilding a valid Caddyfile from the labels the user inputs. The env vars can be replaced later when Caddy actually loads that rebuilt config. If env var replacement was done at that stage, then it would use the env of the controller (the part that is doing the reading of labels off the docker containers), which might not be the correct stuff.
There was a problem hiding this comment.
I don't need want env var replacements.
I have my own in memory representation of caddyfile, that doesn't depend on plugins structs and is still easy to manipulate.
https://github.com/lucaslorentz/caddy-docker-proxy/blob/master/plugin/caddyfile/caddyfile.go
I also have a tiny parser, that parses all tokens into my in memory caddyfile struct:
https://github.com/lucaslorentz/caddy-docker-proxy/blob/master/plugin/caddyfile/marshal.go#L164
Currently, the tokenization is an overlap between caddy implementation and my own implementation. Thus, we're considering exposing that feature.
But, another option, is to expose in caddy a function similar to the existing caddyfile.Parse, but that keeps env variables and snippets untouched. Then I could change my parser to read ServerBlocks returned by parseCaddyfile and tokens from each ServerBlocks.
francislavoie
force-pushed
the
refactor-lexer
branch
from
bcb85af to
2bb6b48
Compare
As requested by @lucaslorentz in this comment https://github.com/lucaslorentz/caddy-docker-proxy/pull/160/files#r449789804
This exposes a
Tokenizefunction which was only in the lexer test previously to do the work of lexing bytes as input to get the list of tokens.One quirk that I'm not sure how best to handle is the
filenameparam. In other languages I'd make that an optional param, but Go doesn't have that, so I'm just using""as the empty value to keepFilenil.