dev meeting 20210218

Present at the meeting:

• Jérémie Diminio (@jeremiedimino)
• Sonja Heinze (@pitag-ha)
• Nathan Rebours (@NathanReb)

Current Plan

• Sonja keeps on working on Astlib
• Sonja uses the opam-monorepo workflow to check if removing the Lexer module from the public API would break downstream users

Meeting notes

Nathan has written a post on discuss to announce the latest ppxlib release and to explain the opam-monorepo workflow of maintaining an up-to-date ppx ecosystem when bumbing the internal ppxlib AST.

Sonja has worked on Astlib. Rebasing it over master revealed two problems: one, it didn't compile when the compiler's AST and ppxlib's internal AST were different. That's fixed. And two, as a consequence of using implicit_transitive_deps false, she needed to define the internal dependency of ppxlib on ppxlib_ast as re-exported ((re_export ppxlib_ast)) for the new cram tests to work. That's not ideal, because ppxlib_ast is a private API. We discussed the possibility to fold ppxlib_ast into the main ppxlib library directly. However making sure that that wouldn't introduce a dependency cycle would require a bit of work. So for now, re-exporting the ppxlib_ast dependency is good enough.

Sonja has also started getting rid of ppxlib's uses of the compiler-lib's Misc module to keep the Astlib API small. One of those users gets leaked through the module Lexer which shouldn't be public in the first place and also leaks the compiler-libs Lexer module directly. We've discussed the possiblity of removing the Lexer module from the public API. Sonja will check, using the opam-monorepo and rev-deps-script workflow, if that would break downstream users.

We've also discussed other users in ppxlib of compiler-lib's Misc and how to get rid of them.

Sonja also made several test binaries private that, being public, unintentionally get installed along with ppxlib in its last two versions (0.21.0 and 0.22.0).