Markdown library OMD seeking mantainer!

[nojb]

Dear community,

The OMD markdown library GitHub - ocaml/omd: extensible Markdown library and tool in "pure OCaml" is urgently seeking a new maintainer!

I have been its nominal maintainer for the last few years (see below for a more detailed description of the current status of the library), but my day job and other higher-priority projects do not leave me enough time to work on OMD. Because of this, there hasn’t been a new release of the library since late 2014.

With this in mind, I am posting this with the hope that someone interested in taking up maintainership of the library will step forward. I will be happy to help this person get up to speed, share what I know, etc.

A bit of background about the current status of the library:

This library (which among other things is used to build the website ocaml.org) had its last release in late 2014. When I took over maintainership circa 2018, I embarked on a big rewrite of the code with the following objectives:

1. make OMD Commonmark-compliant (see https://commonmark.org/);
2. add a proper test suite;
3. simplify the parsing code which was so complex that it was virtually impossible to extend, modify, etc;
4. simplify/improve the internal AST representation which is the main interface used by library clients;
5. add support for some markdown extensions

The current status is as follows:

• (1) and (2) are mostly done: the full commonmark test suite passes with the exception of a few edge cases.
• (3) is only partially accomplished; there is still a lot of room for improvements here, but this is an implementation issue, so it doesn’t need to happen before the next release;
• (4) is also only partially accomplished and there are some open questions as to what the best design would be (see Should AST preserve as much as possible of the original markdown? · Issue #223 · ocaml/omd · GitHub and Could we refine the representation of the AST? · Issue #228 · ocaml/omd · GitHub for some related discussion).
• (5) no progress (this point is related to (4) due to the need to represent extensions in the AST).

I’ll stop here. Please speak up if you are interested, or if you have any questions, I am happy to provide more information.

Cheers,
Nicolás

cc @jfrolich @clecat @antron @shonfeder who have been active in the Github repository.

[antron]

@nojb, Thanks. Is it possible to do some kind of 2.0.0~alpha1 release, that doesn’t promise any API stability, but still offers the command-line tool? Would this mess up users of OMD that depend on the API? Or is this a new API anyway, so no existing user would be broken that wouldn’t be broken by 2.0.0?

[antron]

To add a bit of background, I used to use OMD, and eventually switched away to JS libraries because the old OMD didn’t handle some ordinary cases (I don’t remember the details). I would like to switch back (and I do still use the old OMD when it is suitable). I just need the omd binary for my purposes.

Of course, I can pin the repo for my own usage, but this is both (1) slightly annoying for me (2) not reasonable to expect of downstream users in projects that have them.

Based on this experience, my impression is that OMD is really languishing, but that could be substantially (though not completely) fixed by releasing the current code if omd works.

[nojb]

@antron

Is it possible to do some kind of 2.0.0~alpha1 release, that doesn’t promise any API stability, but still offers the command-line tool?

Yes, this is possible. I’m not sure if OPAM has any special support for such “alpha” or “unstable” releases, but at most a user who wants to stay with the last stable version will have to pin it explicitly.

I will try to do this in the next few days.

Cheers,
Nicolás

[sonologico]

I use it heavily on a couple of projects and would like to see it continue in a good state. I would be open to taking it. Having said that, if one of the already active contributors is up for it, that probably makes more sense.

[shonfeder]

I’m only able to work on OCaml projects in my free time, and this makes my availability somewhat limited and unpredictable, but I’d be happy to maintain (or co-maintain, along with @sonologico or other interested folks). Even with my limits on time, I could certainly commit to timely review of contributions, to regular releases of packages, and to helping advance the state of the code (when time permits).

As an aside, re: (2), I believe the pending PR proposing the use of TyXML for HTML rendering enables the entire suite to pass: Omd_tyxml by shonfeder · Pull Request #211 · ocaml/omd · GitHub

[mseri]

I don’t think there is any special machinery, but many packages have ~alpha and ~beta releases.

If you make the release we can use the opam-ci to check if anything is broken, add the relevant upper bounds and ping the interested maintainers. I will be happy to help with the release if needed

[antron]

@mseri, I believe ~ does get a bit of special treatment: opam - Manual

[mseri]

Oh in that sense yes. I misunderstood what was intended, I was thinking about preventing automatic upgrade to alpha/beta releases.

[nojb]

@mseri

I will be happy to help with the release if needed

Thanks for the offer! I sent you a message on Slack.

Cheers,
Nicolás

[nojb]

@antron

Is it possible to do some kind of 2.0.0~alpha1 release, that doesn’t promise any API stability, but still offers the command-line tool?

Thanks to the efforts of @mseri, this is now available in OPAM (version 2.0.0~alpha1).

Cheers,
Nicolás

[nojb]

@sonologico

I use it heavily on a couple of projects and would like to see it continue in a good state. I would be open to taking it. Having said that, if one of the already active contributors is up for it, that probably makes more sense.

@shonfeder

I’d be happy to maintain (or co-maintain, along with @sonologico or other interested folks).

@sonologico @shonfeder That’s great! I have sent you both a private message to arrange a video chat to discuss next steps. Thanks!

Best wishes,
Nicolas

[gasche]

For people who are curious about how OMD compares to the competition (in other languages) in terms of performance, I ran some benchmarks which suggests that OMD 1.x was not state-of-the-art, while OMD 2.x is: the native-compiled version is faster than fast Javascript implementations running over Node.js.