TIL what shared environments are. Sorry everyone for spreading confusion! 
So to summarize:
(@v1.8)) is stacked by default (via the LOAD_PATH), so beware of accidentally using packages from it.This might help: https://github.com/JuliaLang/Pkg.jl
A āsharedā environment is simply an environment that exists in
~/.julia/environments. The defaultv1.8environment is therefore a shared environment.Shared environments have a
@before their name in the Pkg REPL prompt.
This documentation is confusing though because user-generated shared environments do not work the same way as the default shared environment (unless you explicitly alter the LOAD_PATH) as lmiq says:
(@v1.8) pkg> activate @DataFramesTest
Activating project at `C:\Users\nboyer.AIP\.julia\environments\DataFramesTest`
(@DataFramesTest) pkg> st
Status `C:\Users\nboyer.AIP\.julia\environments\DataFramesTest\Project.toml`
[a93c6f00] DataFrames v1.5.0 `https://github.com/JuliaData/DataFrames.jl.git#main`
[08abe8d2] PrettyTables v2.2.2
(@DataFramesTest) pkg> activate --temp
Activating new project at `C:\Users\nboyer.AIP\AppData\Local\Temp\jl_nosSqz`
(jl_nosSqz) pkg> st
Status `C:\Users\nboyer.AIP\AppData\Local\Temp\jl_nosSqz\Project.toml` (empty project)
julia> using DataFrames # Local environment does not stack with user-generated shared environment.
ā Package DataFrames not found, but a package named DataFrames is available from a registry.
ā Install package?
ā (jl_nosSqz) pkg> add DataFrames
ā (y/n/o) [y]:
Also user-generated shared environments still stack with the default shared environment. (This is probably a good thing, but it is confusing.) You cannot escape the default (1.8) environment:
(@v1.8) pkg> st
Status `C:\Users\nboyer.AIP\.julia\environments\v1.8\Project.toml`
[6e4b80f9] BenchmarkTools v1.3.2
[f68482b8] Cthulhu v2.8.0
[5903a43b] Infiltrator v1.6.3
ā [5fb14364] OhMyREPL v0.5.14
[14b8a8f1] PkgTemplates v0.7.32
[295af30f] Revise v3.5.1
Info Packages marked with ā have new versions available and may be upgradable.
(@v1.8) pkg> activate @DataFramesTest
Activating project at `C:\Users\nboyer.AIP\.julia\environments\DataFramesTest`
(@DataFramesTest) pkg> st
Status `C:\Users\nboyer.AIP\.julia\environments\DataFramesTest\Project.toml`
[a93c6f00] DataFrames v1.5.0 `https://github.com/JuliaData/DataFrames.jl.git#main`
[08abe8d2] PrettyTables v2.2.2
julia> using BenchmarkTools #Works fine even though not in current shared environment.
Ok now I get why thereās some confusion. Shared environments have nothing special, except being āactivableā from anywhere.
But, because some shared environments are defined in JULIA_LOAD_PATH (namely, ["@", "@v#.#", "@stdlib"], as per julia doc), they looks āspecialā ā¦ while they are not 
Conversely, itās totally fine to set a āregularā environment in JULIA_LOAD_PATH, as the same documentation shows (some paragraphs later) ā¦ which will behave as, say @v1.8 for example.
Hope this clears things up 
Why is this confusing? The docs just state - correctly - that the default environment is a shared environment. That doesnāt imply that therefore any shared environment must have all characteristics of the default environment (such as automatically being included in the load path)?
Iāve said this before, but I wonder if it wouldnāt have been a better choice to keep the concept of a default environment (the one that is activated when you start julia without any particular project/environment options) and the concept of a āstackā environment (the one that is on LOAD_PATH by default) separate. Currently, v1.X plays both of these roles, which, among other reasons, is unfortunate because it is way to easy to (accidentally) inflate the āstackā environment (and not even know about it being stacked on top of other environments). If the āstackā environment would be separate, one would have to be very explicit about adding packages to it and for the naive user it would just be empty.
Had never thought much about environments (except for using --temp often for throwaways) but I like that opinion.
This has been discussed in other threads, and could be solved by starting Julia by default in a temporary environment. Then, adding the shared/stacked packages to a new āstackā environment, explicitly, that is in the path by default and shared. I like that idea.
Also, I also often use Pkg.UPDATED_REGISTRY_THIS_SESSION[] = true; before activating a temporary env. This avoid updating the package repository when creating the environment. Just saves time for something temporary.
Hi. Iām ussing Jupyterlab over 1.8.5 Julialang server. I can adjust the ālinewidthāsā plot in a totaly confortable way without āRevise pkg.ā Even more, givent that my 1.8.5 Julialang server is running in a Virtual Machine using notebooks is the easier way for me.
I understood that a script (and VSCode of course) would be ussesfull if I` ll have to generate a dozen (o more) plots after have found the ānicerā linewidth. Then I wouldnĀ“t need āReviseā any more, and Iā ll run the script in a batch mode.
But I donĀ“t know if this was the ācentralā idea of the article or I have loose something ā¦
Is there a IJulia version (with Jupyterlab) running in Julia 1.9+ ?
I am not very familiar with development with notebooks (less still with Jupyter), so I cannot really say what are the advantages or disadvantages for one specific use.
Iām not a huge fan of notebooks, for instance in a small test here I tried using Plots in an empty Jupyter notebook and after a couple of minutes waiting I got āunable to connect to kernelā:
Iām sure that everything being setup correctly the experience must be better, but I usually donāt like the hidden extra layers of complexity that those higher level interfaces imply.
The example of the plot is one example that applies to any other development: using Revise you can develop any function with that very interactive workflow. VSCode is not even really required, you can have just a script in an open file in any editor and an open Julia section in a terminal window, where you have includet() the script.
(the reason I adopted VSCode is mostly because of its integration with github, but this is a point not directly related to the OP)
That has nothing to do with Plots ā if you got that error then it would fail for 1+1. Jupyter/IJulia is misconfigured on your machine. You need IJulia in your default environment (at least, for the default kernel).
Hi again,
1.- Notebooks are very good to ātryā and ātestā.Also are a good tool to āshareā with other people.
I alsi think we are needed of a pure Julia notebooks tool.
The error that "unable to connect " is almost sure for a bad configuration.
2.- ā¦ Yes I know I not need VSCode editor but I have tested others and VSCode gives me the best experience at the moment.
Than you.
IĀ“m sure that it is a bad configuration. I didnĀ“t want to imply anything else. My point there is only that there is a (small) configuration barrier for using notebooks that is not much different from other workflows. That said, Iām not against anyone using and preferring them for any task. Its just not my preference.
Pluto is one such notebook, with very nice features. I use it to some things, presentations in particular, but I donāt like it as a practical tool for everyday experimental coding.
JupyterLab running your nice example in a Julia_1.8.5 on Virtual_Machine.
Thatās always like that. In 1.9 the first run is faster if you use environments (and Pluto does).
OK thanks.
Iād also add workflow for module reloading, since it is brittle and there are some corner cases:
(AFAIK, Revise just automates this process, binding it to the next REPL command.)
include("mymodule.jl") and import .MyModule1.exportāed names are not realoaded (this point is missing from docs, so Iāve spent some hard time to find out this), so donāt pollute your global namespace with using and write import MyModule1 as my and make all calls with my.Foo