Hi all, I’d like to try Bonsai to develop a web frontend, since I gave up hope of using Reason and related ecosystem.
The version present in opam (v0.14.0) has no examples, while the master on GitHub seems much more complete in that sense but I failed to compile the library because it relies on library not present in opam or versions not released yet.
So I created a new switch and pinned all the relevant dev-repo but still no success. For example I can’t find any “1.0.6+newsyntax” version of gen_js_api, required by the latest virtual_dom.
I usually create a new switch with the janestreet-bleeding repo and that should let you install the v0.15 preview of bonsai. Then the examples from the repo should work.
Precisely because “people used to call”. The API is changing too much to be used in production, at least for us.
In our use case we build web interface to control industrial plant and we have to provide updates, bug fixes, new features (read: entire new lines of production) over 20+ years.
We need “OCaml in the browser”, not “Javascript with fancy syntax and static typing”.
Don’t take my words the wrong way: I really appreciate the project, especially ReasonReact, but we need something we can live with for a long time, without worrying a lot about it.
Well, the ReasonReact API hasn’t really changed–only the rename from BuckleScript to ReScript (which has been done in a completely backward-compatible way, breaking nothing).
I don’t think the janestreet-bleeding repo solves the problem in this case. The problem is that gen_js_api.1.0.6+newsyntax refers to some package that exists neither in that repo (gen_js_api is not a Jane Street package) nor in the main opam repo. So there’s no way to install the dependency that is needed by the latest version of Bonsai.
Here is what happens when I try to install Bonsai on a fresh switch with janestreet-bleeding:
$ opam install 'bonsai.v0.15~preview.124.13+29'
The following dependencies couldn't be met:
- bonsai → virtual_dom >= v0.15~preview.124.13+29 → gen_js_api >= 1.0.6+newsyntax
no matching version
No solution found, exiting
Odd it seems opam wants to downgrade my version of bonsai now as well. I’m using ocaml-4.10.0+flambda with bonsai v0.15~preview.123.18+275 which should be close enough to the examples I believe. So hopefully the repo gets updated to include this new dependency.
Oh, I just figured out how to do it without having to fuss around with pins or downgrades: there’s an external-packages branch of janestreet/opam-repository. So just do something like:
Thinking about the churn in web ui frameworks and methods of communicating with servers, I would give up on the web browser and use a desktop application using some framework that hasn’t changed too much (qt?) talking to graphql, in such a setting
If you need a virtual dom, I think it is worth trying out ocaml-vdom, a mature package from Lexifi. I am trying it out and I found them very welcoming. However installation is still a bit of a pain, here is how I installed it in case you want to give it a try:
# insatll gen_js_api-1.0.6
wget https://github.com/LexiFi/gen_js_api/archive/v1.0.6.tar.gz
tar xzvf v1.0.6.tar.gz
cd gen_js_api-1.0.6/
opam install opam-installer
make all
opam install .
cd ..
# install ocaml-vdom
git clone https://github.com/LexiFi/ocaml-vdom.git
cd ocaml-vdom
make all
opam install odoc
make doc
make examples
opam install .
(I am about to use it with eliom/ocsigen for the back-end, but any back-end is fine)
Best !
Looks like a deprecation warning rather than something more fatal.
If you vendor cohttp-async into the project you’re trying to build with bonsai then you could disable the warnings as errors behaviour of dune. FAQ — Dune documentation
@lambda_foo Appreciate your help. Your tip on converting all warnings-as-errors (which dune does) to just normal warnings is a useful one – though it didn’t seem to work for this issue.
I was able to get this compiling in way I found purely by luck.
Notice my error above complains about cohttp-async . If I explicitly type:
$ opam install cohttp-async
The following actions will be performed:
- downgrade conduit 4.0.0 to 2.3.0 [required by conduit-async]
- downgrade conduit-async 4.0.0 to 2.3.0 [required by cohttp-async]
- install cohttp-async 4.0.0+async
===== 1 to install | 2 to downgrade =====
Do you want to continue? [Y/n] Y
...
...
By this direct invocation, cohttp-async mysteriously compiles and then I’m able to proceed with the original $ opam install . --deps-only step. Note that some packages are downgraded. This seems to do the trick.
I’m using opam 2.1 so this could be some constraint solving issue (I haven’t tried with opam 2.0.x)
Its possible some of the contraints are wrong?
Anyways I now have bonsai bleeding edge compiled locally.
Out of curiosity, I looked into this for 5 minutes. I’m on opam 2.0 and got the same error as you did. It does seem like one of the constraints is too wide and including versions that’s aren’t compatible.