Open akshayka opened 1 month ago
So I feel like islands is (are?) pretty close. But there are a few options for completion:
MarimoIslandGenerator.from_file
to the CLI count?Conversely, adapting some of my solutions:
_extension
Aside but food for thought: I also have a mkdocs plugin that's a fork of https://jspaezp.github.io/mkquartodocs/ but it's highly personalized atm- only works with the markdown format and uses nix for sandboxed dev environments. Also mkdocs is not a general export
There also could be a hybrid solution that leverages quarto, but exposes a cli endpoint: marimo export myapp site
/ marimo export myapp pdf
I do know we want this in the CLI, but I don't have a strong opinion on what the right solution is.
Which option do you think our users would be best served by?
I think starting from islands from file export, and then potentially expanding or pivoting based on user feedback.
I haven't seen anyone explicitly calling for quarto or a more advanced export, so starting with base functionality seems like the first best step
I wonder if leveraging quarto and other SSG frameworks is better overall.
My hesitation by adding this to the CLI as-is, would lead to more issues and feature-bloat around customizing the title/color-sheme/meta-tags/open-graph tags, etc.
whereas @dmadisetti's quarto plugin opens up a world of possibilities in the quarto ecosystem
I wonder if leveraging quarto and other SSG frameworks is better overall.
Ok, that would be fine too.
Releasing this under marimo-teams gives export capabilities without the dev overhead of putting in templating/ managing exports. This could be a standalone repo or live in marimo, since it just needs the root folder _extension
I'd be down to release as a standalone repo under marimo-team
, maybe that would be easiest?
As far as marimo
is concerned then, we could simply add documentation to docs.marimo.io
telling users how to use the the quarto plugin.
@dmadisetti, is this something you'd like to do? If so I can create a repo (what should it be called?).
Sorry about that, thought I responded.
Here are the options for export:
_extension
folder in root where the extension code is contained. installation will then be quarto add marimo-team/<repo>
. For instance, if marimo root was used then quarto add marimo-team/marimo
. Note this doesn't install deps, marimo has to still be installed on top of this. It might be possible to bundle a zip of marimo with this, but it would be coupled to the quarto extension installation and not the same as whatever is installed locally. (although maybe we can add some checks to mitigate any confusion)pip install marimo-pandoc
(or whatever the package is called), would install marimo, and place the pandoc filter files in the pandoc path for usage.pip install marimo-mkdocs
It's possible to create another repo that includes options 2,3, and 4 of the export options. http://github.com/dmadisetti/quarto-marimo
couples 2 and 3, minus the panflute distribution. My local implementation of the mkdocs plugin leverages the marimo quarto integration, but it could easily be stripped out.
For renderable exports in github, I think a GH action that utilizes the chosen option/s above would be ideal. Options can be to export as markdown or PDF
@dmadisetti — 2 sounds great to me, since you already have an implementation of it, and since Quarto appears to be loved by the community.
How should we proceed? If you like, you're welcome to transfer quarto-marimo
to the marimo-team
organization, or I can create a new repo in marimo-team
, or you can create a PR that adds the _extension
folder to the marimo
repo ... You would know best.
Another option to consider is Myst: https://mystmd.org/guide/quickstart. It recently became part of project Jupyter (https://github.com/jupyter-book/mystmd), and was used for the Scipy 2024 proceedings. I have heard that it is comparable to Quarto.
I've looked at Myst a little before. Their exports look interesting, it's not pandoc based
Their standard is a little different from everyone else and also supports things like inline eval. References might be something that marimo could think about providing greater integration for
Discussed in https://github.com/marimo-team/marimo/discussions/1078