OPAM package

[bryphe]

I'd like to publish an OPAM package for revery to make sure it's usable with the broader OCaml community (which would primarily consume this library via OPAM).

I've only tested it with esy currently, but it would be great to publish and verify this through OPAM.

[bryphe]

⚠️ The list have changed and may change again in next month so we advice you to read our dependencies section ⚠️

I think this will also necessitate packaging up several of the dependencies as OPAM packages:

• reason-gl-matrix
• reason-glfw - reason-sdl2
• reason-fontkit
• reason-reactify - brisk-reconciler
• flex
• rejest - rely

There's also some C/C++ packages we'd need to bundle (I guess as depext) for the relevant libraries:

• glfw - sdl2
• glm
• stb_image
• freetype2
• harfbuzz

Some of the dependencies above depend on esy's environment settings to figure out where to find header files, libs, etc - we'd need to adjust that as well.

[bryphe]

We're also using an unreleased build of JSOO that I'm not sure how to set up in OPAM:

revery/package.json

Line 44 in d3ab0ba

"@opam/js_of_ocaml": "github:ocsigen/js_of_ocaml:js_of_ocaml.opam#db257ce",

[kyldvs]

rejest

I assume we will need to ship Rely to opam as well? I can kick that off!

[bryphe]

@kyldvs - oh ya, good call - that would be great! Just ninja edited my list above.

[jordwalke]

I believe that we can make rely (and even some others) just devDependencies since they're only used while testing the app. I believe jsoo could be a devDependency as well (in some cases - maybe not this one). The latest versions of esy will have a buildDev section in addition to build which we can use to supply a command that is ran when building the top level package. that can build tests/test cases and can rely on you having dev dependencies available.

[nilsbecker]

this would be great! i would love to try out revery, but i'm not familiar with the JS world. i guess it would be ok to read the manual in Reason syntax, as long as i don't have to write it! (as a general remark, i would love to see more Reason libraries that are usable from the Ocaml ecosystem; after all that's one of the advantages of Reason just being a syntax! it would be a shame to miss out on this opportunity for cross-pollination)

[jordwalke]

@nilsbecker The ReasonML umbrella project includes Reason Syntax, as well as the esy workflow which does in fact integrate pretty well with the OCaml ecosystem. You can use esy to install packages that haven't yet been pushed to opam in the mean time, and use whatever syntax you like when consuming them (for example Revery). No JS is involved at all in that case.

[nilsbecker]

thanks for the info. i'm still figuring out what esy does exactly. it seems to be a build system that integrates with npm, which allows it to install pre-built binaries and JS packages. yes? it replaces dune and partially, opam, as opam is used as a source for dependencies. although i deeply dislike the fact of again having several build systems coexisting, i guess dune will never be able to do all of the JS integration that esy does.
is there a way to use dune as a build system together with esy as a dependency manager?

[smolck]

Hello! Is packaging the dependencies mentioned in #71 (comment) all that needs to be done now, or is there more that must be done before that? If not, the only thing that needs to be done is for a member of revery-ui to follow the steps outlined in https://opam.ocaml.org/doc/Packaging.html for the necessary dependencies, right?

I'd like to help with this process where I can; Revery is a really nice library, and being able to use it with OPAM would make it that much better!

[Et7f3]

In fact our .opam file are empty so you have to fill it.

[smolck]

Okay, will do! I'll start with this repo and then create PR's for the OPAM files mentioned in #71 (comment).

[Et7f3]

I think the reverse order is better. Now if you want to build revery you will have to pin lot of package. with we can publish our dependencies and then revery without pinning to mush stuff.

[smolck]

Good point! Will do the reverse then ;)

[smolck]

As for the versions of the packages (in the .opam files), should I match the NPM versions or do something else?

[Et7f3]

opam-version is not the version of the package but the version of the format (the latest is 2 because opam 2 maybe 2.0x) but yeah version should match out json file and don't forget opam lint

[smolck]

opam-version is not the version of the package but the version of the format (the latest is 2 because opam 2 maybe 2.0x) but yeah version should match out json file

I wasn't sure about opam-version, so thanks for clearing that up!

. . . and don't forget opam lint

Could you elaborate on this?

Also, should I put the information in dune-project and then add (generate_opam_files true) to it so that dune generates the necessary .opam file(s), or would you rather I manually modify the .opam file(s)? Here's an example of that BTW: https://github.com/rgrinberg/opium/blob/master/dune-project

[Et7f3]

opam lint say if you opam file are valid if you omit some infos etc.
(generate_opam_files true) is ok just don't forget to put the lower bound of dune. This option wasn't here in dune 1.0.

[Et7f3]

Originally posted by @Et7f3 in revery-ui/reason-glfw#116 (comment)

You haven't run opam lint :) because the lint say we must add a . at the end of synopsys and description. And sorry I hadn't seen the message is outdated. I have added a notice now that is up to date. Revery is know to compile from 4.07 to 4.09 maybe he compile on 4.06 (so just try to compile with 4.06 if you want. If you want to quickly move on you can put this three version.)
Also side note.
We have 3 types of packages
(1) reason-smth that are often binding to (2)esy-smth on npm or (2)conf-smth in opam world so we have a depext to smth.

(3) We have also regular deps that are purely OCaml/ReasonML. some with @opam/ preffix are already on opam so it is less work to do :).

Reason-smth has of course dep to reason (published on OPAM)

[jordwalke]

We are planning on releasing the reason-native packages to opam fwiw. That might help if anything in Revery land depends on them. Maintaining the same packages in two universes is pretty cumbersome though. And it can cause serious issues if some dependency depends on the opam one and another dependency depends on the npm one - you will get link time failures. The approach we want to go with moving forward is that all packages (reason, esy, opam, anything really ) needs to have its library name include a very unique prefix like (library (public_name opam__revery)) or (library (public_name npmscope__revery)) so that just in case they both get linked into a binary they don't cause a conflict. I think we might need a little dune/opam support to make this happen and make it usable. We have some discussion on the dune repo about this - it really requires that users be able to re-alias the libraries when importing them like Revery = require('@opam/revery')

[smolck]

Maintaining the same packages in two universes is pretty cumbersome though.

Is this necessary though? Esy can use opam packages, so why not shift focus to opam instead of NPM? Existing Revery projects would need to switch over to using the opam packages, but that should be straightforward (change revery to @opam/revery in the Esy package.json file and things should mostly “just work”, right?). And anyone wanting to use dune without esy should then only need to run $ opam install revery and add it as a dependency to the necessary dune files.

[aryx]

Does releasing revery in OPAM still on the roadmap? I would love to use revery in my own OCaml project.