[ANN] Ppxlib `trunk` support (non-continuous)

Hi everyone,

To guarantee good compiler quality, it’s important that everyone can use trunk in their projects in all different ways: locally, in benchmark CIs, in behavior CIs etc. A typical blocker for that used to be: you have a (possibly transitive) PPX dependency and not a trunk-compatible version of Ppxlib at hand.

To avoid that situation as a strict blocker, we’ve just created a branch on the Ppxlib repo with trunk support. So whenever you want to use trunk on a project with PPXs, pin your Ppxlib to that branch. This doesn’t guarantee continuous compatibility. When the compiler modifies the parsetree, the branch won’t compile until we manually adapt it. Don’t hesitate to open a PR or an issue when that’s the case!

There’s a difference between Ppxlib supporting and building with trunk as your compiler and Ppxlib supporting the new trunk syntax features. This branch only serves the former. I’ve tried to make clear what that difference means on the README of the branch.

Btw, the ideal and most convenient solution for trunk support would be to upstream Astlib to the compiler. We’re currently not working on that, though.

Happy trunk-testing!

Cc @shym, @otini, @shakthimaan, @avsm and @nojb, who I know/think are particularly interested in this.

11 Likes

Hi again,

to avoid further misunderstandings: I’ve been made aware that

Btw, the ideal and most convenient solution for trunk support would be to upstream Astlib to the compiler. We’re currently not working on that, though.

might send a wrong message. So let me explain a bit better:

Astlib is the intersection library between Ppxlib and the compiler. It currently forms part of Ppxlib. However, we want to upstream it to the compiler one day. That’s where it belongs from a coherent design point of view, but most importantly it would have an important practical advantage: Ppxlib would become continuously compatible with trunk and any stable compiler version. So the branch I’ve announced here would become unnecessary and trunk-testing would never be blocked or made complicated by Ppxlib.

As mentioned before, we currently don’t have “upstream Astlib” on our high priority list of tasks. That’s partly because it wasn’t necessary during the compiler’s feature-freeze phase for 5.0 development. However, we do plan to come back to it at some point. When we come back to it, the first step will be to discuss it with the compiler maintainers, since it was a long time ago that we last discussed it and that they accepted to take on the review and maintenance burden.

2 Likes

Hi @pitag,

This is great news! I know transitively depending on a non-compatible ppxlib has blocked me on several occasions. Thanks for all your work on this.

1 Like