I am pleased to announce that ppx_show is now available in opam. ppx_show reimplements the show plugin provided by ppx_deriving as a ppxlib plugin. In particular, ppx_show is available with OCaml 4.08.0 (and is available on all OCaml versions compatible with ppxlib, starting from 4.04.1).
See @arbipher’s related question.
Sounds nice! Some questions/remarks:
ppx_deriving base plugins and ppxlib plugins like this one?show plugin by this implementation? ()gitlab.inria.fr which does not let external contributors send Pull/Merge requests. If I wanted to contribute to your codebase – and in my experience with ppx derivers, adoption means that people will want to send you code – I would just fork a mirror at another host.It looks like it works, apart from the name clash that prevents ppx_show to be used together with ppx_deriving.std (since both libraries want to register a deriver called show).
I think so, but I think it would only have sense if the other plugins are reimplemented as well.
I could do that, but I was unsure about the overlap with other existing ppx libraries (like ppx_compare, ppx_enumerate, etc.). If the community feels a need for a systematic portage of ppx_deriving plugins with stronger compatibility requirements than those provided by these libraries, I would be willing to work on it.
I would like that gitlab.inria.fr be more open for external contributors; meanwhile, I encourage potential contributors to do such forks.
Looks to me like the Inria instance of GitLab already allows external contributors to register and send pull requests.
At first, it doesn’t allow to login through GitHub account, like most of the GitLab instances do. Most of the people would prefer to avoid registering in one more service among thousands. Secondly, once the account is established, I recommend to check the lab command line GitLab and GitHub client, it can streamline sending pull-requests and moving code back and forth between GitHub and GitLab. See for example lab merge-request for creating new MR/PRs and lab mr for managing existing ones. More in their documentation.
@thierry-martinez in practice I’m maintaining ppx_deriving and its plugins, but I never had the time to work on a ppxlib port – I’m in bug-fixing and minimal-porting-to-new-release maintenance mode. If you (or someone else!) were willing to work on a ppxlib port (or just ocaml-migrate-parsetree integration), that would be very nice, and I would encourage you to replace the existing code instead of adding another alternative – that is, provided that compatibility is good enough for user-experience to be preserved.
Note: I think there are interesting questions to be explored around ppx_deriving (for example, how should deriving work on GADT declarations? Can we support everything, or at least a subset?); I would be happy to discuss it on the occasion.
Thanks for this (and for an old post be remembered)!
Regarding the ppxlib port, what will happen when Future of PPX will become ready? Will it require rewriting the ppxlib itself, will it be a drop-in alternative implementation, or everything based on it should be rewritten instead?
Also created bugs to track the possible porting to ppxlib:
The short answer is: we don’t know yet. I think the AST format will change, requiring a rewrite of preprocessors.
To ensure good backward/forward compatibility, the AST types will become abstract. So ppx rewriters will need to be ported from ppxlib to ppx. However, ppx was initially forked from ppxlib so the API will be familiar if you know ppxlib. In any case, we will make sure that old and new ppx rewriters can be used together on the same files. This will ensure that we don’t need to upgrade the whole world at once.