# Nice workflows for using and developing in Julia 1.9+
**URL:** https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017
**Category:** General Usage
**Tags:** tutorials
**Created:** [March 13, 2023, 5:48pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017 "2023-03-13T17:48:17Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@cstjean](https://discourse.julialang.org/u/cstjean)
#### Post date: [March 17, 2023, 3:17pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/21 "2023-03-17T15:17:18Z")
TIL what shared environments are. Sorry everyone for spreading confusion! š«¢
So to summarize:
- Activating a shared environment is fine
- Stacking is generally fine, but can be dangerous
- The default environment (aka `(@v1.8)`) is stacked by default (via the LOAD\_PATH), so beware of accidentally using packages from it.
---
### Author:  [@Barget](https://discourse.julialang.org/u/Barget)
#### Post date: [March 17, 2023, 3:19pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/22 "2023-03-17T15:19:26Z")
This might help: [https://github.com/JuliaLang/Pkg.jl](https://github.com/JuliaLang/Pkg.jl/blob/master/docs/src/environments.md)
---
### Author:  [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)
#### Post date: [March 17, 2023, 3:49pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/23 "2023-03-17T15:49:11Z")
> [@Barget](#):
>
> This might help: [https://github.com/JuliaLang/Pkg.jl](https://github.com/JuliaLang/Pkg.jl/blob/d5d64708d5924a256903b28c7362fc6cad66da74/docs/src/environments.md#shared-environments)
> A āsharedā environment is simply an environment that exists in `~/.julia/environments`. The default `v1.8` environment 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:
> [@lmiq](#):
>
> That applies to the āmainā shared environment only. You cannot load packages from other shared environments without explicitly activating them first, and in that sense they behave the same as any other environment, as far as I understand.
```julia
(@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:
```julia
(@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.
```
---
### Author:  [@Barget](https://discourse.julialang.org/u/Barget)
#### Post date: [March 17, 2023, 3:59pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/24 "2023-03-17T15:59:54Z")
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](https://docs.julialang.org/en/v1/manual/environment-variables/#JULIA_LOAD_PATH)), 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 š
---
### Author:  [@nilshg](https://discourse.julialang.org/u/nilshg)
#### Post date: [March 17, 2023, 4:29pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/25 "2023-03-17T16:29:36Z")
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)?
---
### Author:  [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)
#### Post date: [March 17, 2023, 5:18pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/26 "2023-03-17T17:18:08Z")
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.
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [March 17, 2023, 6:02pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/27 "2023-03-17T18:02:51Z")
> [@carstenbauer](#):
>
> 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.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [March 17, 2023, 7:23pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/28 "2023-03-17T19:23:46Z")
> [@carstenbauer](#):
>
> 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).
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.
---
### Author:  [@Emmanuel-R8](https://discourse.julialang.org/u/Emmanuel-R8)
#### Post date: [March 24, 2023, 3:02am UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/29 "2023-03-24T03:02:19Z")
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.
---
### Author:  [@fer2tdt](https://discourse.julialang.org/u/fer2tdt)
#### Post date: [March 28, 2023, 12:30pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/30 "2023-03-28T12:30:12Z")
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+ ?
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [March 28, 2023, 2:10pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/31 "2023-03-28T14:10:59Z")
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)
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [March 28, 2023, 2:28pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/32 "2023-03-28T14:28:50Z")
> [@lmiq](#):
>
> 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ā:
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).
---
### Author:  [@fer2tdt](https://discourse.julialang.org/u/fer2tdt)
#### Post date: [March 28, 2023, 3:38pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/33 "2023-03-28T15:38:18Z")
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.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [March 28, 2023, 4:52pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/34 "2023-03-28T16:52:29Z")
> [@stevengj](#):
>
> 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).
> [@fer2tdt](#):
>
> The error that "unable to connect " is almost sure for a bad configuration.
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.
> [@fer2tdt](#):
>
> I alsi think we are needed of a pure Julia notebooks tool.
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.
---
### Author:  [@fer2tdt](https://discourse.julialang.org/u/fer2tdt)
#### Post date: [March 31, 2023, 7:59am UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/35 "2023-03-31T07:59:50Z")
---
### Author:  [@fer2tdt](https://discourse.julialang.org/u/fer2tdt)
#### Post date: [March 31, 2023, 8:02am UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/36 "2023-03-31T08:02:44Z")
JupyterLab running your nice example in a Julia\_1.8.5 on Virtual\_Machine.
---
### Author:  [@fer2tdt](https://discourse.julialang.org/u/fer2tdt)
#### Post date: [April 6, 2023, 8:43am UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/37 "2023-04-06T08:43:04Z")
> [@lmiq](#):
>
> `@time my_plot(data)`
Here we have the same example in Pluto.
We can see that in Pluto, only the first ārunā has a significant cost. Then it suggests us that the can make the first run like a test with few points (by minimizing problem āsizeā). Then, after we have the ārecompilation doneā we could launch the definitive run.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [April 6, 2023, 9:37am UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/38 "2023-04-06T09:37:19Z")
Thatās always like that. In 1.9 the _first_ run is faster if you use environments (and Pluto does).
---
### Author:  [@fer2tdt](https://discourse.julialang.org/u/fer2tdt)
#### Post date: [April 6, 2023, 11:56am UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/39 "2023-04-06T11:56:41Z")
OK thanks.
---
### Author:  [@sairus7](https://discourse.julialang.org/u/sairus7)
#### Post date: [April 6, 2023, 6:25pm UTC](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017/40 "2023-04-06T18:25:04Z")
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.)
- All type definitions should be placed inside module in a separate file.
- Script files should have `include("mymodule.jl")` and `import .MyModule1`.
- First change definitions within module, then re-run script files.
- `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`
- All above is unnecessary if you are already working only inside the module.
[Previous page](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017.md?page=1)
[Next page](https://discourse.julialang.org/t/nice-workflows-for-using-and-developing-in-julia-1-9/96017.md?page=3)