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

Moving away from mustache #95

Open
Zimmi48 opened this issue Apr 4, 2021 · 6 comments
Open

Moving away from mustache #95

Zimmi48 opened this issue Apr 4, 2021 · 6 comments
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@Zimmi48
Copy link
Member

Zimmi48 commented Apr 4, 2021

Mustache is a pretty limited template language. In particular with respect to conditionals. Here are some options for moving away from it:

  • Use Ruby. I don't know this language yet but I heard it's pretty well suited for advanced templating (in particular with ERB IIUC).

  • Parse the meta.yml file and generate everything in OCaml. IINM, there doesn't exist a YAML parser in OCaml but there is a new parser for a variant of it which is probably very suitable for what we do with this language: https://github.com/chetmurthy/yay

@Zimmi48 Zimmi48 added question Further information is requested help wanted Extra attention is needed enhancement New feature or request labels Apr 4, 2021
@Zimmi48
Copy link
Member Author

Zimmi48 commented Apr 12, 2021

I've just learned about an OCaml templating project: https://github.com/EmileTrotignon/embedded_ocaml_templates

Together with YAY, this might be enough to move away from mustache without having to learn Ruby.

@erikmd
Copy link
Member

erikmd commented Oct 22, 2021

@Zimmi48 just told me about this issue;
indeed, it seems a good idea to (1) use a more expressive template language than mustache, and (2) moving from shell scripts to ocaml code.
But maybe in this case it could be possible to use the pyyaml package together with a Python/OCaml binding such as pyml?
In this case we wouldn't need to restrict ourselves to the YAY fragment of YAML.
But it may happen that the current contents of meta.yml is already fully compatible with YAY.

@Zimmi48
Copy link
Member Author

Zimmi48 commented Oct 22, 2021

FTR, if YAY was not a satisfying solution and we wanted a true YAML library, we wouldn't need to go through such a route: there's also https://github.com/avsm/ocaml-yaml which provides OCaml bindings on top of the libyaml C library.

@intoverflow
Copy link

In my humble opinion it would be nice to keep the non-OCaml dependencies to a minimum. The Coq ecosystem is already coupled to OCaml. It may be expedient to write the tooling in Python or Ruby, but doing so adds Yet Another Language Ecosystem to the stack of things a user would need to setup in order to use the tool.

Instead of complicating our tech stack with extra language dependencies, I'd like to advocate for making the proper investments into OCaml to make it suitable for this task - especially if the primary consideration is whether or not there's a YAML parser that's up to the task.

@Zimmi48
Copy link
Member Author

Zimmi48 commented Feb 16, 2022

We (Karl and I) are in agreement that it's better to depend on the OCaml ecosystem because it will make it easier for Coq users to contribute than if we were to use, say Ruby. So this is what we plan for the v2 of the templates.

Regarding the question of a YAML parser, there are actually two options: the YAY (full OCaml) parser and the ocaml-yaml library (both were mentioned above). So we should be fine.

@erikmd
Copy link
Member

erikmd commented Mar 8, 2022

Just in case FYI (this is not an objection, I'm very fine with the latest comment by @Zimmi48):

there would also be the solution of using a bash script + yq, see e.g.:

https://stackoverflow.com/questions/71393380/fetch-variables-values-from-yml-and-pass-to-shell-script/71397858#71397858

Pros: lighter, no language barrier such as that of ruby
Cons: more fragile, and bash is not statically type-checked :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants