As I see it, a primary concern of Pluto is ensuring the shareability of notebooks. (There, I just invented a word.) And for this reason, Pluto requires packages to be registered. Am I not correct? However, sometimes and a package in question is under development and registration doesn’t make sense. I’ve read about setting up some kind of local registry as a work around.
Q: Is this advisable? Are there any gotchas?
I would very much like to use Pluto to show off my package as a work-in-progress over, let’s say, a Zoom meeting. Sharing the whole notebook then is not necessary and even undesirable.
Thanks for the response.
I read the docs on LocalRegistry.jl.
Apparently, I can point it to a local repository, and opposed to a remote, then take advantage of Revise, which I have also read up on. Because I am the sole user, I can them go to town. Do I have this all correct?
The use cases for both are orthogonal:
With LocalRegistry, you are working on specific versions of your package (analogue to registered packages), which are stored in the notebook and guarantee reprocibility. But updates are rather slow because you need to register a new version and then update the package version in your notebook.
With Revise, you automatically get all updates you are doing in the package in real-time, but you loose reproducibility.
The LocalRegistry method is imho better suited for using internal packages, whereas the Revise method is better for developing packages.
It’s possible to keep using Pluto Pkg manager for registered packages, and ]develop WIP packages manually. Possible and simple, but not documented or officially supported.
Just execute
function Pluto.use_plutopkg(topology::Pluto.NotebookTopology)
!any(values(topology.nodes)) do node
Symbol("Pkg.activate") ∈ node.references ||
Symbol("Pkg.API.activate") ∈ node.references ||
Symbol("quickactivate") ∈ node.references ||
Symbol("@quickactivate") ∈ node.references
end
end
before Pluto.run(), and freely use Pkg.add and Pkg.develop in notebooks.