Neptune.jl is a non-reactive fork of Pluto.jl. It looks and works exactly
like Pluto, with one key difference: cells do not automatically re-run when
other cells change.
Editing a cell runs only that cell
Notebooks do not auto-run when opened
Multiple cells can define the same variable without error
Everything else — the UI, package management, @bind widgets, exports — is
identical to Pluto
This makes Neptune better suited to workflows where cells are expensive to
compute, you’re iterating on a single cell, or you simply want Jupyter-style
manual control with a cleaner interface.
Install:
import Pkg
Pkg.add("Neptune")
Usage:
using Neptune
Neptune.run()
Neptune can open .jl notebooks saved by Pluto — both formats are supported.
Source: https://github.com/compleathorseplayer/Neptune.jl
All credit for the underlying notebook platform goes to
https://github.com/fonsp and the Pluto.jl contributors.
How does this compare to Jupyter in detail? I personally don’t think a cleaner interface would justify the tool’s necessity. Some elaboration would help!
Multiple cells can define the same variable without error
That makes a huge difference. Neptune is usable for code that takes a long time to load and to re-evaluate, where Ploto is not.
And yes, this could also be a configuration option for Pluto, but as far as I remember the Pluto developer did not want to add that to his code base. Correct me if I am wrong.
Hello! It’s good to see that you find most of Pluto useful and the source code easy-to-work with! I was just a bit surprised by the MAINTAINING.md; you seem to ask for the authors field of the Project.toml to be set to your name. That’s not really accurate in terms of the effort; given that you patch 11 commits on the Pluto source right?
What I propose instead:
Add your name to the list, (also, something similar for the LICENSE I would guess, but I am not a lawyer) OR
Pluto is pretty extensible as is. Make a package that depends on Pluto and applies the patches on the julia runtime. You can probably make this more modular if you apply some patches upstream, we will be happy to review contributions towards maintainability. This approach most likely doesn’t need maintenance anyway. And you’ll definitely be the sole author of that
All in all, I welcome your contribution to the julia ecosystem! It’s good to see traction and discussions again!!
I was comparing Neptune to Jupyter, not Pluto. Jupyter is basically as OP described already, only running a single cell at a time. OP mentioned
I was curious about what other niches/benefits Neptune could provide, other than ‘a cleaner interface’ which is a bit subjective. This is considering Jupyter is a more mature and established tool with no obvious downsides.
I’d argue that your NotPluto has the exact same maintainance problems as Pluto.jl does, and in many ways it’s worse.
By maintaining a Pluto fork, every time Pluto releases an update, you can just use git to compare if Pluto changed any of the lines Neptune changed, and then either just cleanly update, or take whatever actions need to be taken in order to adapt to changes in the source.
NotPluto on the other hand needs hard version caps on Pluto down to the sub-sub-version to make sure it doesn’t get broken by upstream changes to pluto, and the process of finding out if changes to Pluto will break NonPluto is more cumbersome and manual than the process of updating Neptune. The claim of “~0 maintenance” is just wrong.
If Pluto had generic APIs for the things that @compleat wants to overload, then of course something like NotPluto would be preferred, but if the only way to hook into these things is agressive type piracy and completely overwriting existing methods at startup time, that’s just bad practice with no upside.
Pluto is a highly opinonated tool though, and requests for customization APIs like that have been routinely rejected, so I don’t see what @compleat could do here other than fork.
Sure, I can’t argue with that. I’m just demonstrating how the alternative would work. I don’t actually plan to maintain NotPluto.jl (I do plan to maintain Pluto though. will vaguely try to break neither).
With claude, we are all victims of “The Lisp Curse”; it’s a new world we live it
In Makeitso.jl I also implemented a declarative, non-reactive framework to deal with scripts built from long-running expensive tasks.
It takes the cue from GNU make for its syntax. Recipe definition and build requests are separated. Moreover, the output of each cell is backed up to disk using JLD2, meaning that script execution can even survive a kernel crash. Targets can be parametrised and for-loops creating a target for a range of parameters are supported by the syntax.
I like some ideas of Pluto: full julia stack, notebooks as valid JL scripts, cool interactivity… but I need only sometimes the reactivity mechanism (mainly short/demo/teaching scripts).
I really believe that a Pluto option to enable/disable reactivity (and, as follows, allowing multiple commands per cell) in a given notebook would be a much better outcome for the community than keeping 2 separate projects.
It’s important to remember for the discussion and questions that have been asked, Neptune is a 6-year old project started shortly after the release of Pluto, so a lot of the features Pluto currently has (like easy cell disabling) may not have been implemented when Neptune began.
