-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate Website Stack options #354
Comments
From @yarikoptic |
i would vote for hugo instead of jekyll today. or just a jupyter-book or quarto or some such which can bring some of computation elements into our site as well. |
I've also used hugo to build operatorframework.io and for the most part I thought it was pretty nice. In that case, I chose hugo to align with the rest of the kubernetes community, which uses Hugo heavily (including kubernetes.io itself) Hugo's integration with netlify was very good (free hosting for open source projects) and included PR previews "out of the box". The challenging part of working with Hugo for my previous use case was the theme stuff. In particular, extending the docsy theme was problematic, though the theme was still pretty new all those years ago. |
FWIW I included sphinx because this is a python-heavy community, but I suspect its not the right choice for us. Its been a while but I found the rst-style was more cumbersome than the markdown used by Hugo or Jekyll. I suspect our community would prefer using very similar syntax to GitHub rather than learning rst. |
@satra can you elaborate what you have in mind for computational elements? (I imagine live jupyter notebooks would be really cool) IMO, this is a strong reason to continue focus on the high level requirements prior to making the stack choices. |
here are some examples of data books:
it's all markdown based and also notebooks that can be embedded. in terms of requirements, being able to execute a notebook might allow us to do some things like process data to generate figures of stats or other things from courses, usage, etc.,. i would put it as a nice to have, but not necessary requirement. |
for mkdocs we are now about to include them via mkdocs-jupyter in dandi/handbook#145 . And if need arises we could always add them up somehow e.g. as in https://medium.com/@romankurnovskii/how-to-add-jupyter-cuaderno-in-hugo-static-site-67cfdb42653f . And for interactive ones, we better run a hub anyways ;-) |
Lets put together a pros/cons list of various options.
To name a few:
The text was updated successfully, but these errors were encountered: