Literate.jl
Literate.jl copied to clipboard
WIP: Output Pluto-flavored notebooks.
Also, appears to be convenient tohave options fold_markdown_cells and fold_code_cells (as I remarked in the pluto thread).
This is not recorded in the file from what I can tell, so not sure how that would be possible.
Also, appears to be convenient tohave options fold_markdown_cells and fold_code_cells (as I remarked in the pluto thread).
This is not recorded in the file from what I can tell, so not sure how that would be possible.
Folding of cells (if I correctly understand what is meant by that) does appear to be encoded in the file - compare the following two lines
# ╟─4470b440-ed68-11ea-1bfe-f349b617e30a
# ╠═7357b150-ed68-11ea-2d87-bbe8febe80ec
The first is folded and the second is unfolded.
Thanks for doing this, I'm looking forward to being able to use it!
Oh wow, that is extremely subtle. I was also looking at the wrong place, it was in the list of UUIDs and not for the cells.
Okay, you can now fold cells with cell metadata. I set the default to fold markdown (why would you ever want to show it?) and to show for code.
Oh wow, that is extremely subtle. I was also looking at the wrong place, it was in the list of UUIDs and not for the cells.
Yes, I ended up reading the notebook loading code in Pluto to find out how it was storing the folded state!
Hey @fredrikekre, thanks for working on this! I don't mean to push you, but I'd really love to use Pluto flavored notebooks in my homepage using Literate.jl
. Could you please tell me how far along this is? I can't wait to use it!
I think it works, please try it.
I think it works, please try it.
Worked for me with Julia 1.5 , https://juliaclimate.github.io/IndividualDisplacements.jl/dev/basics/random_flow_field/ , on macOS
Super useful feature that I will frequently use to turn doc examples into interactive demos. Sometimes Pluto.jl
helps me uncover bugs / faults in my examples too.
As I first tried to run this in the very folder where the original file is (i.e. Literate.notebook("random_flow_field.jl", ".", execute = true, documenter = false, flavor=:pluto)
), I can also say that the error message worked. The .jl
file that was generated with ".." then worked via Pluto.run()
-- except for a variable being defined twice with the same name (easy fix, my bad).
Thanks @fredrikekre !!!
Is the reverse (i.e. Pluto to Documenter/Literate ingestion) also feasible? I feel it should be and I would use that too. Maybe that case is already treated or planned?
What work needs to be done here to merge? I'd be happy to help with finishing touches.
Does it work? I have not really tested this with anything fancy.
since this has been in the works for a while and has been requested by many people, maybe it would be good to merge now and fix residual problems as they come up
I can try this next week, I'll be away from my computer until then.
Again this would be great to have merged so we can use it, even if incomplete or a bit buggy.
But it seems to work fine for me.
Is the reverse (i.e. Pluto to Documenter/Literate ingestion) also feasible? I feel it should be and I would use that too. Maybe that case is already treated or planned?
Since this comment, I realized that I could just use PlutoSliderServer.jl as part of building the docs and move files in place as needed. In case that helps someone else with their use case, there is an example in ClimateModels.jl
What is currently blocking merging this as-is - Is it just a rebase and getting the tests passing?
Basically I just lack self-interest in this feature since I am not such a huge fan of Pluto notebooks. It is quite a different format and requires quite a lot of special casing in my experience so not so easy to map directly between formats. But if people still like this I can rebase and merge, but help with maintanence would certainly be appreciated.
I'll probably use this in a low-key way for documentation going forward, so I'd be happy to fix any bugs I find with it.
I'm encountering strange behaviour when generating a markdown file within the same script. So this works fine:
# Literate.markdown(@__FILE__, DIR_OUTPUT, execute=false) #src
Literate.notebook(@__FILE__, DIR_OUTPUT, execute=true) #src
Literate.notebook(@__FILE__, DIR_OUTPUT, execute=false, flavor=:pluto) #src
But this
Literate.markdown(@__FILE__, DIR_OUTPUT, execute=false) #src
Literate.notebook(@__FILE__, DIR_OUTPUT, execute=true) #src
Literate.notebook(@__FILE__, DIR_OUTPUT, execute=false, flavor=:pluto) #src
throws an error, even though the keyword "flavor=:pluto" is not specified in Literate.markdown(...)
and the markdown
call happens first.
ERROR: LoadError: UndefKeywordError: keyword argument flavor not assigned
Stacktrace:
[1] markdown(inputfile::String, outputdir::String; config::Dict{Any, Any}, kwargs::Base.Iterators.Pairs{Symbol, Bool, Tuple{Symbol}, NamedTuple{(:execute,), Tuple{Bool}}})
@ Literate ~/.julia/packages/Literate/XvlLA/src/Literate.jl:420
[2] top-level scope
@ ~/Google Drive/Julia/HelloJulia/tutorials/lightning_tour/src/lightning_tour.jl:100
[3] include(fname::String)
@ Base.MainInclude ./client.jl:444
[4] top-level scope
@ REPL[10]:1
in expression starting at /Users/anthony/Google Drive/Julia/HelloJulia/tutorials/lightning_tour/src/lightning_tour.jl:100
Are you using Literate from within Literate?
Do you mean, am I calling the conversion from within the script I want converted? Yes. It's a convenient workflow. Should I not do this?
Okay, recent changes seem to have broken something. Now I can't get pluto converter to work at all. Here's a MWE
using Pkg
Pkg.activate(temp=true)
Pkg.add(url="https://github.com/fredrikekre/Literate.jl", rev="fe/pluto")
#-
x = 1:100
#-
y = rand(100)
using Literate #src
const DIR_OUTPUT = joinpath(DIR, "..") #src
Literate.notebook(@__FILE__, DIR_OUTPUT, flavor=:pluto) #src
If I execute this file I get
[ Info: generating notebook from `~/GoogleDrive/Julia/HelloJulia/tutorials/test/src/tutorial
.jl`
ERROR: LoadError: TypeError: in typeassert, expected Literate.AbstractFlavor, got a value of type Symbol
Stacktrace:
[1] preprocessor(inputfile::String, outputdir::String; user_config::Dict{Any, Any}, user_kwargs::Base.Iterators.Pairs{Symbol, Symbol, Tuple{Symbol}, NamedTuple{(:flavor,), Tuple{Symbol}}}, type::Symbol)
@ Literate ~/.julia/packages/Literate/cWsLt/src/Literate.jl:400
[2] notebook(inputfile::String, outputdir::String; config::Dict{Any, Any}, kwargs::Base.Iterators.Pairs{Symbol, Symbol, Tuple{Symbol}, NamedTuple{(:flavor,), Tuple{Symbol}}})
@ Literate ~/.julia/packages/Literate/cWsLt/src/Literate.jl:615
[3] top-level scope
@ ~/julia/HelloJulia/tutorials/test/src/tutorial.jl:20
[4] include(fname::String)
@ Base.MainInclude ./client.jl:444
[5] top-level scope
@ REPL[14]:1
in expression starting at /Users/anthony/julia/HelloJulia/tutorials/test/src/tutorial.jl:20
If I create a separate file to generate the conversion I get the same error.
Literate.notebook(@__FILE__, DIR_OUTPUT, flavor=:pluto) #src
I updated from using a symbol to use flavor = Literate.PlutoFlavor()
.
I wonder if a better design would be to regard Pluto notebooks and Juptyer notebooks as completely separate, rather than two "notebook" flavours. The reason is they require different processing because of differences in figure handling and package management, for example. With a single filter #nb
I'm not able to distinguish them.
added Mmm. It actually seems that #nb only signals a contribution to the Juptyer notebooks, and not the Pluto ones??
Pluto.jl output would be a great feature to have, I think, esp. to offer tutorials and the like in script, Jupyter and Pluto format.