No. I need LiveServer to view the documentation of my own packages. Like this:
Script build_docu.jlin the scripts folder of my packages:
# build and display the html documentation locally
# you must have installed the package LiveServer in your global environment
using Pkg
function globaldependencies()
projectpath = Pkg.project().path
basepath, _ = splitdir(projectpath)
Pkg.activate()
Pkg.update()
globaldependencies = keys(Pkg.project().dependencies)
Pkg.activate(basepath)
globaldependencies
end
if !("LiveServer" in globaldependencies())
println("Installing LiveServer globally!")
run(`julia -e 'using Pkg; Pkg.add("LiveServer")'`)
end
if !("Documenter" ∈ keys(Pkg.project().dependencies))
using TestEnv
TestEnv.activate()
end
using LiveServer; servedocs(launch_browser=true)
Oh interesting I’ve never heard of your ShareAdd.jl. I’ve tried multiple shared environments before but exactly found it to be more of a hassle than it benefitted. I’ll have to check this out!
DaemonMode.jl looks pretty cool! My first thought it that it’s kind of a non-trivial “hello world” of multiprocessing. Now that I think about it, it could also be useful for tmux-like persistent computations after you leave ssh?
Yeah – just keep DaemonMode.jl running in the background, and then you can execute scripts against it without having to go through standard/first time compilation all over again.
I find it particularly helpful with other programs that want to call Julia – DaemonMode makes it pretty easy to just keep a single Julia process rather than restarting it every time.
I was initially worried about the fact that it hasn’t had releases in a while, but it works just fine.
By default, an agent will run a script as julia my_script.jl, see what’s broken, and then try to fix it. This is slow because of startup time + recompiling functions. By starting a Daemon and then running scripts, the test feedback loop is much faster.
nohup julia --startup-file=no -e "using Revise; using DaemonMode; serve(;shared=true)" > daemon.log 2>&1 &
julia --startup-file=no -e "using DaemonMode; runargs()" script.jl
# Remove global environment from load path
let
i = findfirst(==("@v#.#"), LOAD_PATH)
if !isnothing(i)
deleteat!(LOAD_PATH, i)
end
end
Too many times I have added packages in the global environment by mistake, and then I forgot to add them in the local environment (because it was working!), resulting in non-reproducible projects and possibly corrupted state where incompatible packages where used together. Because as the documentation says:
Packages in non-primary environments can end up using incompatible versions of their dependencies even if their own environments are entirely compatible. This can happen when one of their dependencies is shadowed by a version in an earlier environment in the stack (either by graph or path, or both).
I’ve ranted about this before (a bit too vehemently) here. The gist of it is that I don’t understand why Julia would use incompatible package versions by default, instead of showing an error and maybe having an opt-in setting to allow it (suggested name: yolo=yes).
That definitely makes sense. Though the biggest one on the other side for me is Plots.jl. I usually want to plot stuff when I’m testing functionality/making examples/actually doing something with it, but don’t want the package itself to directly depend on Plots.
TerminalPager.jl is invaluable for reading long docstrings or outputs, it’s practically the first package I install in any new Julia version. A lot of people also use it for viewing tabular data (eg. DataFrames), though I generally go straight to Jupyter or Pluto for those.
My preferred way of using TerminalPager is to use the | key to change the REPL mode: it shifts into pager> mode after that, and any output that occurs in that mode, if it’s longer than one screen length, gets displayed in pager interface i.e. like less on Linux where you can scroll up and down, search, etc. If you press ? when you’re in pager mode, you get to pager-help mode where the docstrings are displayed the same way. Because Julia’s functions often have many methods, there ends up being screenfuls of docstrings even if each individual doc is pretty short. So TerminalPager makes those docs a lot more manageable and easier to parse.
(Speculator seems to be Jakob’s own package, that I also learnt about from this thread, so I’ll just link to its announcement post that I found today.)
@digital_carver’s description of TerminalPager.jl is excellent and much better than I could give!
Speculator.jl is indeed one of my own packages. It has a feature where it tries to precompile methods in a background thread of your REPL. I’m not sure to what extent this feature is actually useful, but I’m at least using it to ensure it doesn’t break.
@Eben60 I’m curious about the combination of BasicAutoloads.jl and ShareAdd.jl here. Is your setup such that typing DataFrame() will automatically load your @DataFrames shared environment and work?
