Transitive `ppxlib` dependency

[jmid]

While wanting to try out olly on a PR against trunk I spotted a dependency on tracing, which again depends on ppx_jane, which again depends on ppxlib, which requires "ocaml" < "5.2.0". As a consequence, olly cannot be installed on trunk as I tried to :shrug:

This is unfortunate and I therefore wondered if this was accidental or a concious decision?

[Sudha247]

@jmid, this is indeed unfortunate, and I've been bitten by it while trying to use olly on trunk too! The dependency on ppxlib is due to a dependency on tracing library for producing binary format outputs. I'm not sure we can bypass that. Providing a json only package that works with trunk could be an option. Let me also check with ppxlib devs what's the status on trunk, as I recall they were working on trunk support.

[kayceesrk]

Let me also check with ppxlib devs what's the status on trunk, as I recall they were working on trunk support.

Would you know @pitag-ha or @tmattio?

[pitag-ha]

Unless we adapt priorities and allocate more time to ppxlib maintenance, I'd currently not recommend having a project that will likely have users on trunk depend (transitively) on ppxlib. @Sudha247, do you know if it would be viable to drop the tracing dependency?

In my opinion, ppxlib's trunk-support situation is quite disappointing, both for the ppxlib maintainers and for people such as you who're bitten by it. However, we don't have the resources to fix it. Upstreaming Astlib to the compiler, which would be a great solution and would guarantee continuous trunk support, would require several weeks of time investment, which we don't have. And committing to manually add trunk support to ppxlib on every compiler Parsetree change, has turned out to be too time-intense as well.

You're not the only people who're bitten by this problem. About half of the opam ecosystem relies on ppxlib. So users and maintainers of half of the ecosystem can't use OCaml trunk. And trunk integrity or performance CIs, that test trunk on ecosystem packages, are very restricted by this as well. So I'm aware of the problem and am trying to figure out a solution. However, I don't know how much time that will take, so for now, I recommend dropping the transitive ppxlib dependency on projects like olly if that isn't too much work.

[tmcgilchrist]

Do you know if it would be viable to drop the tracing dependency?

We need to retain the ability to write Fuchsia Trace Format. One option would be to swap out tracing for trace-fuchsia which has no ppxlib dependency or to slim down tracing to remove the use of ppxlib. Personally I would prefer one well written and tested library for this purpose that I can use against ocaml trunk.