Forgive me if this is already a thing and I hadn’t noticed but…
What if Opam packages could come with a demo repo?
For example, I’m just trying to see if I can get a basic GUI up and running from OCaml to display a chess board for a project I’m working on. So I reviewed posts about OCaml+GUIs and found labltk, lablgtk, lablgtk3, lablqt, lablqml, lablgl, sdl, graphics and so then. Then I try to find the home page for each project to get their entry level demo. After installing the opam package I have to either clone a repo or dune init project, edit the dune configuration files to use the package I installed and paste source code into bin/main.ml before I can dune exec bin/main.exe only to find out that a package’s Hello World of demos is in a non-working state.
What if you could do something like:
opam install lablgtk demo
and get a demo you can test run and, if it works, develop into an app of your own?
As an aside, popcon stats on opam packages would be extremely useful as in many cases I’m finding they are not in a working state. Would be wonderful to be able to determine that at a glance.
I guess a simpler solution would be to provide a demo repository that you could install with opam install lablgtk-demo
or, if it’s not in the official opam repo, opam pin https://github.com/aaa/mylib-demo.git
Maintaining good demos is certainly extra work for the maintainers, but I agree it’s important and valuable.
Since you mentioned GUI, concerning bogue, from the README you see that, if you just install it you can either:
immediately try the boguex examples that come along to check it they work for you; for instance boguex 7 would be appropriate for this time of year.
try in the toplevel the hello world example of the documentation
That was excactly the idea behind carcass (except that was totally agnostic to tooling, it just generates text files or hierarchies thereof). Basically each package could install it’s own variables and templates in say $(opam var etc)/carcass/$(PKG) to be looked up according to the lookup procedure, properly namespaced by opam/library names.
Never released it because in the end I thought it was better to try to create tools that by design do not need boilerplate… the current amount of bureaucracy and metadata needed for writing the tiniest program is nowadays insane. The existence of boilerplate generation tools does not curb the trend, so I decided not to add one more. (It also would also need a design round to remove the metaphor, it’s cute but a needless burden to learn).
Regarding code samples I think it would be much better to have code extraction from .mld files, see here for the broad idea. That way you can have a tutorial, verify that it compiles, and teach users of the eco-system that they can always:
odoc extract -d hello $(opam var $PKG)/odoc-pages/tutorials/hello.mld
to play with the actual sample. This is a very simple workflow for both authors and users. But people like their complexity.
preach. and when i must have it (ci setup, automated release config, pkg management, etc) I want it as close to the toolkit i’m already working in. fox example, i really like what talex & friends are doing with ocurrent/ocaml-ci. zero config “just does the good stuff” for common sense CI. if i need my own thing, i can do my own thing in ocaml, no some goofy stringy-typed/yaml dsl.