LivebookHelpers - Creating Livebooks From Module docs

Here is a blog post introducing what you can do with it:

This is a very cool hack, but using it still involves a lot of friction. So, I wonder how hard it would be to move the hack into full scale production. For example:

• A daemon could automagically run livebook_helpers on everything in https://hexdocs.pm, etc. The results would be stored somewhere in the cloud.

• A dynamic compendium of livebooks would be distributed, allowing users to import and access the generated livebooks, on demand.

• For extra credit, the compendium might provide an easy way for users to submit feedback to the authors of the hexdocs documents.

-r

This is a very cool hack but…

I think this nicely sums up most of my programming career to date .

Some nice ideas. I think if we were to go that route it could be good to build it into hexdocs itself.
I did try to host for free all the core Elixir module docs on Fly.io but one problem I ran into is there is a bit of a limit on the size of livebook that you can reasonably run.

For example you can’t open or run a livebook created in this manner for the Enum module in Elixir - it’s simply too large.

There isn’t really a workaround for this yet either - each Elixir cell is an instance of the monaco editor so if you have a lot of them the page gets very heavy. See this issue for more.

Someone clueful will no doubt solve the loading latency and resource usage issues. However, to me the more interesting question is: “How should a communal project Livebook for Elixir developers be structured and implemented?”

Since I’ve come up with a bit of a wishlist, here is a speculative description of what this resource might look like. Comments and suggestions welcome… (ducking )

-r

Like @Adzz, I really like the notion of having Hexdocs-based Livebooks (and assorted other resources) made available as a “starting point” for my Livebook project notebooks. Here’s a possible use case:

Starting a new project, I instantiate a new project notebook, based on a specified Git branch. This branch might be a group or individual effort; either way it represents someone’s idea of a useful collection.

The notebook would typically have sections containing example code, library documentation, tools, etc. Some of these would be turned on by default; others would be included and described, but commented out.

Most of these items would be well known and popular, but others’ inclusion might be based on personal preferences. In any case, collectively they would make a well-tuned starting point for projects of a particular nature.

After downloading a canonical starting point, I would start it up. At this point, the Livebook would access and fold in preferences set in local control files. At this point, I would have a “live” notebook, ready for customization for a project.

Of course, this is merely the starting point; some of the gnarlier problems deal with how to handle continuing divergence of local notebooks from current practice, etc. I submit that these sorts of issues are already dealt with in various ways (eg, diffs and patch files). That said, I’ll be as interested as anyone to see what might be done in practice.