Open Rahuketu86 opened 3 years ago
We believe that you can already use Pluto notebooks to write a package, with testing and documentation! We will soon rewrite PlutoUI.jl to a series of Pluto notebooks as a proof-of-concept, so stay tuned!
What do you think is missing for "Literate programming"? The sample notebooks are a good example of this in Pluto
About 3: some people use a semicolon (;) at the end of their cell to disable output display, and then also hide the output. This creates a 'hidden' cell
I think in general, it is the overall cohesiveness of experience I get from something like nbdev + jupyter. One good thing about Pluto.Jl is the fact that it already does a few core things very well eliminating need to implement these features separately:-
Plain Julia format files and reactive kernel ( It pretty much solves a lot of problems mentioned in Joel Grus talk:https://www.youtube.com/watch?v=7jiPeIFXb6U)
Few things which I would like a literate programming environment to enable
Full package development from Pluto.jl ( Even though Pluto.jl is largely focused on exploration, I think with minor tweaks and separate utility package we can achieve this easily.). For me a package development is not just about being able to develop but also enable support for testing, documentation and clean up . This is in context with multiple notebook files
I would love to have following core features ( Lot of these ideas are inspired by nbdev exploratory programming paradigm : A good talk for the same is here : https://www.youtube.com/watch?v=9Q6sLbz37gk&t=5s)
A project template with ( as part of PlutoUtils)
Thanks, those are cool ideas! I will experiment with these things myself for the PlutoUI package first, and we will probably have more to talk about afterwards!
We have a notion page where we write design docs and we'd love your contribution: https://www.notion.so/Pluto-jl-a9982e79b7bb4c658e6216c15a9d4cab Can you send me an email? fons@mit.edu
Is there an update on Pluto => Literate?
I've been using Pluto.jl
extensively and almost exclusively since it's fun and have most functionality I need.
Now, slowly discovering the Documenter.jl
package that is optimized to work with markdowns, I see benefits of the literate documents as documentation pages.
Btw, where does discussion on the Pluto development happen these days?
I am new to Pluto and Julia ecosystem as a whole. I come from the python world. I recently took the task to learn julia and build a package / library in it.
There are a few tools which has become a mainstay of my toolkit in python. They include nbdev and jupyterbook . Nbdev in particular is a literate programming environment for python which combines utilities to develop python packages , documentation, testing and deployment all in a nice useful comprehensive package based on jupyter notebooks. My first impulse for choosing a personal project was to start by implementing a version of nbdev specific to julia language. After exploring a bit more around the julia eco-system & watching a few videos on youtube, I came to know about Pluto.
I now feel Pluto.jl can become base of a much more robust julia package(/ library) development environment or a literate programming tool. However it still lacks a few things to get the same level of productivity I get with nbdev . I believe an extension to Pluto.jl base package or an utility package built around Pluto.jl and providing a workflow for package management can help achieve the same. I would like to file this issue to put forth some of those ideas into discussion
Pluto.jl at present is very much an alternative for jupyter. As such it concentrates on individual julia file without providing any workflow or utility for library development or literate programming
Package documentation : An utility which can do bulk export of multiple Pluto.jl notebooks into something like an executable book site(https://jupyterbook.org/start/build.html) or nbdev (jekyll -documentation) site(https://nbdev.fast.ai/) can be incredibly useful
Concept of export cells/ flags : If an utility can be built which can introduce concept of flags limiting export / visibility of certain cells . It can go a long way for a more fine-grained documentation and control.
Concept of testing +code coverage+ combination with build actions similar to nbdev.