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

Can we specify stdin as a datasource? #230

Closed
ghost opened this issue Nov 7, 2017 · 4 comments
Closed

Can we specify stdin as a datasource? #230

ghost opened this issue Nov 7, 2017 · 4 comments
Assignees

Comments

@ghost
Copy link

ghost commented Nov 7, 2017

Use case example:

generates_some_yaml | gomplate --file template.yaml --datasource config=-
@hairyhenderson
Copy link
Owner

Hi @josdotso, thanks for the feature request! I think this sounds reasonable. I'll see what I can do!

@hairyhenderson
Copy link
Owner

@josdotso there's a hitch with your suggested syntax... gomplate decides how to parse a datasource based on either the file's MIME type, or file extension. When using stdin, obviously we lose that information.

How about providing a fake filename with a stdin URL scheme? Something like this:

generates_some_yaml | gomplate --file template.yaml --datasource config=stdin:///config.yaml

Another approach could be to allow setting/overriding the MIME type directly as a URL query parameter, like this:

generates_some_yaml | gomplate --file template.yaml --datasource config=stdin://?type=application/yaml

Obviously more verbose, though the same approach could be applied generally to other datasource types to allow overriding the MIME type... 🤔

I think there's still value in allowing -, if you're just going to include the data and don't need it to be parsed, but otherwise a type will be necessary for parsing.

@ghost
Copy link
Author

ghost commented Nov 8, 2017

Thanks for the feedback!

Any method would be fine with me. I actually ran into the mime issue with a something.yaml.tmp that I rendered as a workaround. I think the first example is my favorite of the two.

@hairyhenderson
Copy link
Owner

Ok! I like both approaches, and I may add the second as a more general flexibility thing... But for now I'll implement the first 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant