Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transitive ppxlib dependency #30

Open
jmid opened this issue Oct 23, 2023 · 4 comments
Open

Transitive ppxlib dependency #30

jmid opened this issue Oct 23, 2023 · 4 comments

Comments

@jmid
Copy link
Contributor

jmid commented Oct 23, 2023

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 🤷

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

@Sudha247
Copy link
Member

Sudha247 commented Nov 1, 2023

@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
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants