Add support for embedded variables in headers
Hey,
Thanks for this awesome generator!
Unfortunately, I can't use it to fetch GitHub's own schemas because they require Authorization headers in the form of Bearer token. Currently, the generator only supports variable expansion if it's the only element in the header value. However, I can't hardcode the token in my pyproject.toml to work around this limitation.
So I added support for embedded and multiple variables (not that I need multiple variables, but you basically get that for free with my approach, so why not...). There may be situations where it won't work like shell, but I would prefer simplicity over handling all possible corner cases.
Hope this helps you and others!
This looks like a duplicate of #332
Did you consider storing Bearer $YOUR_TOKEN in a variable instead? See https://github.com/mirumee/ariadne-codegen/issues/231#issuecomment-1770433611
This looks like a duplicate of #332
Sorry about that! I should have searched for other PRs before opening mine.
As far as I'm concerned, it doesn't really matter which PR gets merged. I'll take a look at your code.
Did you consider storing
Bearer $YOUR_TOKENin a variable instead? See #231 (comment)
Yes, I did - but it's an ugly and clumsy hack. All tools (GitHub CLI, SDKs, etc.) standardize on GITHUB_TOKEN, and if I set GITHUB_TOKEN to Bearer ... it will break them. I can only set a second variable specifically for Ariadne like export ARIADNE_GITHUB_TOKEN="Bearer $GITHUB_TOKEN".
But what's worse is the very annoying and confusing default behavior. I've never seen a tool that claims to support "variables", but only resolves a variable if it's the only content of the string. This is not documented and extremely counterintuitive.
In fact, it's so confusing that I didn't even know what to search for and ended up debugging the code to figure out why I was getting 401 or 403 no matter what I tried. At that point, implementing proper variable support, including tests, only took a quarter of an hour, and I didn't bother looking for issues.
So if you decide to reject the PR, please at least document the weird notion of the variable directly where variables are mentioned, to save others searching and re-implementing the same.