-
Notifications
You must be signed in to change notification settings - Fork 96
Dev Meeting 2024 06 18
- 5.2 AST bump
- Driver Transform refactoring
- 5.3 support
- Added a trunk CI build, we should be able to consider merging
- Still need documentation for releases
- Driver anti-warning 34 code gen
- Still haven't heard from Janestreet, we need their feedback before moving forward with this
- Ocamlfind support
- There seem to be a bug when a ppxlib based ppx is invoked directly using ocamlfind -package
- Is this something we want to actively maintain
- Dune w/ ppx
- Nathan got back to it, hopefully it should be ready soon
- Repo hygiene: issue triage
- We have a lot of issues, most of which are extremely old
- A lot of issues are actually questions on how to use ppxlib for ppx authors
- It's worth having a go at closing the irrelevant issues and have some classification system for the rest
- Nathan
- Sonja
- Patrick
- Carl
- Shon
The code that manipulates the registered Driver.Transform.t could be greatly simplified. We have been discussing this in previous meetings and Patrick already started working on it. We need to clarify exactly what we want from this refactoring and whether this has to be done all at once or we can identify intermediate steps. In particular it would be nice to clearly identify the builtin context-free phases using the type system rather than identifying them using the transformation name string which is passed by the users and could potentially collide.
Action-point:
- Nathan and Patrick are going to discuss this and find out if a good refactor would be viable. Next Monday or Tuesday.
We now have a working trunk CI build which will greatly help with maintaining the 5.3 support. It already detected that our 5.3 support PR was out of date. Nathan is working on fixing it but we should then be able to merge. Nathan also added a RELEASE.md file to the repo, as part of the 5.3 PR, to describe how to handle 5.3 support when cutting ppxlib releases before the stable compiler release.
We still need to add an action on the compiler to ping ppxlib maintainers on PRs that modify parts of the compiler-libs that will impact ppxlib.
Action-point:
- Nathan adds an action to ping us on compiler PRs
- Nathan fixes the 5.3 support PR ✔️
Has been done and announced. Good resonance about it! But one package author has reported a bug report wrt ocamlfind. Shouldn't be much effort to fix but it opens
General question: How much do we support ocamlfind workflows (as opposed to dune)? We might ask on discuss and/or a ppxlib issue how many people still rely on ocamlfind.
Patrick has worked on the work on ppxlib. Mostly done. Next step: Doing the reverse dependencies fixes. There are different approaches we could use:
- The ppx universe approach we've used so far
- Building all reverse devs in a CI.
We'll probably go down the second route. We're also communicating with other people working on reverse deps CIs.
Nathan added a flag to disable the generation of warning 34 silencing items when using [@@deriving] that was successfully used by Mathieu Barbin. Before going forward and merging this we needed to know a bit more about why this was added in the first place.
At Jane Street they do have code, where they only define a type to derive code from it without using the type directly. Those are Jane Street internal PPXs, though. Carl will look into the Jane Street code to see if that can be cleaned up. Jane Street is probably not greatly dependent on that feature. Removing it all together would be better from a Ppxlib maintenance point of view.
If it happens we can't remove it, we'll likely provide a transition scenario similar to what we did for warnings 32 and 60 countermeasures. We unfortunately cannot reuse the same flag for compatibility reason but we can add a new flag that disable all such anti warnings features.
Those flags should support a third force value that disable the feature whether the derivers opted in or not so that regular users can already turn them off if they wish.
Action-point:
- Carl looks into the Jane Street code to see if it can be cleaned up to avoid relying on Ppxlib silencing the 34 warning.
- Nathan works on the implem based on Carl's feedback.
Our issue tracker is filled with issues and it's making it hard to use it correctly. We need to spend some time cleaning it up, closing irrelevant or resolved issues and classifying the remaining ones.
This is quite time consuming though and we lack the resources to do that at the moment. We should maybe consider closing all issues older than some threshold, letting the authors decide whether they are still relevant.
Nathan has resumed work on that. Will discuss more with Rudi.