From our last release, yocaml must have a conflict with result.1.5 to be installable via opam in any switches (see this commit b58cc7d). This error is not really related to yocaml (as a well known issue from opam-repository's maintainers). @xvw proposed to use Result from preface which should be nice and should fix the initial issue:

A quick fix on YOCaml part can be replacing Result.map_error by Preface.Result.Bifunctor.map_snd. It is a little bit heavy but it should work.

Initially, the project was just an empty shell to experiment a bit with the Preface API. But it turns out that the project is quite fun and I'm really happy to see that OCaml (since the last time I really used it, in 2008) has evolved a lot, the ecosystem is rich, the language has interesting features and ... Dune! So I decided to try to make this project... something useful (at least for myself)!

Currently, it is only possible to build pages statically by concatenation. Although I have some fairly specific ideas (inspired by the venerable Make) of how to improve the user experience. But, being completely unfamiliar with the OCaml ecosystem, I have several questions about how to properly speed up this project.

Open questions

• Writing articles in a markup format is fashionable (Markdown, Org, AsciiDoc). I don't have a preference so I'll probably take the one best supported by OCaml. What are the "standard" projects? Should I write a wrapper over the Pandoc CLI?
• Templates and metadata injection. It is quite common for a static blog generator to offer to inject directly into a template values built on the basis of an article (date, author, tags, description, title etc.). This generally implies having a template logic. Are there already projects of this type?
• Where and how to write this metadata? In the article/page file, in a separate file (JSON, TOML, YAML, SEXP?). What are the ideal libraries to transform this textual data into structured data? (And how to validate them, probably via Validate ;) and how to inject them into a template?)

If you have any suggestions, whether we know each other or not, I'm interested! Thank you in advance.

Currently, tests must be a part of the yocaml_yaml package when these tests include some of yocaml (see this commit 3ddf9b0). It will be nice to split out tests instead of including all of them into one package.

By reading https://lobste.rs/s/u0vzv8/yocaml_yet_another_static_site_generator#c_xshetm (reported by @xvw)

@dmbaturin (who is the creator of Soupault which is in the list of alternatives presented in the documentation) says this

Mustache can be quite limiting. Unless it’s a very deliberate design choice, I’d recommend switching to Jingoo.

I don't have a strong opinion on which template language to use, which metadata protocol to recommend, and which markup to use (although, as an Emacs user, I'm pretty biased on the issue ;) Org for the win) but I find it a bit sad that YOCaml is "biased" in a very dirigiste direction. As a funny note, I know that @xvw is using this project using Org as the Markup language, and its key value description language (Brick I believe) to describe the compile target metadata, which indicates that the Engine is flexible enough to accommodate various choices.

My suggestion would be to once again (as was done for the extraction of the Unix dependent modules) split the project by adding a new part:

• yocaml_engine containing only the Engine (Effect, Build, Runtime and Deps and all the modules needed to run them) and an abstract approach to metadata processing (abstracting to key/value providers using, why not, Json as a "base", which seems very compatible with Yaml) and template processing. An abstraction on the markup doesn't seem necessary to me because, in fact, it's nothing more than a string to string function modulo errors.
• yocaml_unix which, as now, would only be a runtime for Unix. Nothing should be changed on this side.
• yocaml which would contain a concrete use of the engine, describing several metadata (pages, article, articles, like now) and a concrete version of the metadata and the template engine (with by default, if you really like it, mustach, Yaml and Markdown)

yocaml would give an "example" of how to build concrete representations of the abstraction on value keys, how to change its markup and how to choose its own template language.

It's either the wrong URL or a private repository: https://github.com/xvw/preface

Hello, it would be cool if YOcaml supported the Atom syndication format similarly to Yocaml.Rss module (Atom seems to be more used on the Geminispace 😛). I can make a patch to add this feature myself, but I saw that you use your own way to generate XML. I was thinking of using xmln, but that would be inconsistent with the Yocaml.Rss implementation. Is adding the dependency acceptable, and should I write the Atom support with it and leave the task of rewriting Yocaml.Rss to you?

Thanks!

By following the tutorial I had to change YOCaml to Yocaml here

Hi, I would like to host my blog on Gemini space and would like to know the necessary changes to make to support Gemini's own format: Gemtext. Would it be possible to indicate them to me? Maybe I'll make a PR.

Thank you 🙂

Hi!
I realise that this project has taken on more weight than it was created for, but the fact that the paths are concrete (an alias on String) raises several concerns:

• In Yocaml_irmin (https://github.com/xhtmlboi/yocaml/blob/main/lib/yocaml_irmin/runtime.ml#L23) each file must be exploded (which is quite fragile because the runtime assumes that all separators require only one character). Here we would like to be able to simply describe the path as a list of fragments.
• Since there is a trivial transformation, the case of Irmin is not so problematic. On the other hand, if I wanted to integrate a runtime that uses, for example, a remote server (or a database) as a source, I'd have to be tricky (for example by creating my own interpreter or by parsing, in the manner of Yocaml_irmin a path to transform it into a valid HTTP request).

My suggestion is to abstract the Path within the Runtime to make it easier to describe different types of resources.

Coucou

Comme tu l'as reconnu ici, "wordpress" est un nom un tantinet trop... controversé.

Je propose "yocaml".
(ou YoCaml, yOCaml, yoCaml, yo_caml, etc. comme tu préfères)

yocaml

Ça n'existe pas (sauf dans les archives d'une mailing-list de 2004), ça dit "yo" comme les petits jeunes de maintenant qui font tous du OCaml, les vieux vont rager d'avoir manqué d'autant de swagitude, les gens font des sites web et des blogs pour dire "yo" aux autres gens, ça peut faire référence au Yaml utilisé et c'est un "λ" en miroir suivi de "OCaml".

Petit logo vite-fait d'un λ en miroir avec des bosses de chameau qui forme un merveilleux "yo" camélisé :

Le même logo en SVG :

<svg width="100" height="100" version="1.1" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
  <path d="m50 1.217c-26.94 0-48.78 21.72-48.78 48.51s21.84 48.51 48.78 48.51c9.737-0.02434 19.24-2.945 27.3-8.386 4.17 3.708 9.786 6.98 17.93 8.487-3.828-6.744-6.011-11.97-7.029-18.61 6.818-8.533 10.55-19.1 10.59-30 0-26.79-21.84-48.51-48.78-48.51z" fill="#f6f8fa" stroke="#1f2d3d" stroke-width="2"/>
  <path d="m80.32 68.83c-0.05106-9.313-6.093-16.47-14.59-16.58-9.923 0.279-14.53 8.616-14.61 16.58 0.04065 9.346 6.105 16.5 14.61 16.61 9.884-0.3043 14.51-8.678 14.59-16.61zm-5.493 0c0.0791 6.27-3.029 11.97-9.089 12.05-7.108-0.2167-9.079-6.83-9.118-12.05-0.05883-6.235 3.102-11.94 9.118-12.02 6.984 0.2513 9.048 6.845 9.089 12.02z" fill="#1f2d3d"/>
  <path d="m50.39 21.7c-7.234 0.2938-9.01 8.649-10.07 13.44l-3.838 17.26-13.34-30.07h-8.454l19.15 41.02c-1.205 4.918-2.793 15.74-8.991 15.6-4.549-0.1055-6.352-4.312-6.58-7.899h-1.606c0.2107 5.736 2.553 14.64 8.892 14.41 4.874-0.1797 7.248-5.101 8.321-8.757 3.668-12.5 5.057-20.77 8.15-33.91 1.176-4.996 2.865-14.59 9.13-14.68 3.34-0.04173 5.382 2.33 5.676 7.027 0.3592 5.728 2.546 15.38 8.893 14.41 11.21-1.718 8.661-21.06 17-21.44 3.122-0.141 4.981 2.931 5.574 7.033h1.705c-0.1023-5.366-2.231-13.38-8.039-13.44-11.62-0.1202-7.232 21.45-16.95 21.33-4.494-0.05381-6.499-4.328-6.58-7.9-0.1258-5.56-1.832-13.69-8.047-13.44z" fill="#1f2d3d"/>
</svg>

Le même logo sublimé par la puissance d'un chameau provenant d'un édifiant article de la BBC :

Qu'en penses-tu ? 🙃