There is a version of the code you are running here, which also includes a set of environment files Project.tom and Manifest.toml, for reproducing the same environment. (If you just run the script there as is, in the same folder as these files, it should use that environment automatically). I’m unable to reproduce your problems with that script/env. I also updated the environment there with using Pkg.update() and again, no problems. In this case I have these versions installed:
Also note that if you use the current Pluto version, the package versions in your notebook might be different from those in your default (or any other) environment, as Pluto’s built-in package manager will create a notebook-specific environment once you put using somewhere in your notebook.
I think it’s nice for reproducibility and mitigates compat issues especially for new users which might not use environments otherwise, but I agree it can be surprising for people that do ] st or other package operations in the REPL to find that they have no effect on the code in their notebooks…
By the way, it’s usually more convenient if you can copy and paste code snippets into code blocks, rather than posting screenshots. See here for more info:
Ok, well I still think that printed output and stacktraces are easier to read when they are in code blocks than when they are presented as screenshots.
No, I think you misunderstood my point. Any command you type after pkg> is run in the environment pkg, and therefore will not affect the Pluto notebook, which generates its own environment. E.g. if you did
pkg> add DataFrames@1.0
in the REPL, then
julia> using Pluto; Pluto.run()
and then put
using DataFrames
at the top of your notebook, Pluto will automatically install the latest DataFrames version (1.2) in your notebook environment, and you will be using that version in the notebook, not the version in your pkg environment from which you started Pluto.
Correct. You can do using Pkg, Pkg.activate("/path/to/pkg") in your Pluto notebook to manage your own environment and disable Pluto’s built-in package manager, but if you don’t do that there’s no point doing any package operations in the REPL prior to starting Pluto (except for changing the version of Pluto itself, obviously).