When executing some code at REPL startup in VS Code by adding "-e ..." to julia.additionalArgs in ./.vscode/settings.json, I noticed that Ctrl+Enter / Execute code in REPL does not work for a new REPL (where the code after -e is executed). Additionally, clicking on Choose Current Module (Main) in the bottom-right corner of VS Code shows the message “Setting a module requires an active REPL.”, indicating that the obtained REPL is not properly recognised.
MWE settings.json
{
"julia.additionalArgs": ["-e println(\"a\")"]
}
System info
Julia (ran in the VS Code REPL, with the “a” print):
a
julia> versioninfo()
Julia Version 1.11.2
Commit 5e9a32e7af (2024-12-01 20:02 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: 8 × Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
WORD_SIZE: 64
LLVM: libLLVM-16.0.6 (ORCJIT, skylake)
Threads: 8 default, 0 interactive, 4 GC (on 8 virtual cores)
Environment:
JULIA_NUM_THREADS = 8
JULIA_EDITOR = code
Is this expected behaviour, or a bug? Is there an easy fix?
In all cases, what would in general be the preferred way to run a piece of code when starting a project-specific REPL? (More specifically, I want to push! to LOAD_PATH in order to add development-time dependencies (which I don’t want to place in the Base environment). My attempted approach was then similar to Create an implicit environment with package directories - #16 by francis-gagnon, but suffers from the issue described above.)
Expected behaviour. Only one of -e and a file can be supplied at any time (see below) and the extension needs to load Julia with an internal startup file.
❯ cat test.jl
println("file")
❯ julia -e 'println("cmd")' test.jl
cmd
❯ julia test.jl -e 'println("cmd")'
file
(More specifically, I want to push! to LOAD_PATH in order to add development-time dependencies (which I don’t want to place in the Base environment
Consider using a normal environment for that. Generally, I’d caution against LOAD_PATH modifications.
I see, it indeed needs to load terminalserver.jl. Barring some hacky "-e (...); include(\".../terminalserver.jl\")" solution, I guess settings.json is not the appropriate place to run some project-specific development startup code.
My issue is then indeed also more of a Julia design choice, rather than anything related to the VS code extension itself.
To clarify, my idea was to have a basic project environment with the essential packages for running and testing the code, and then load a development environment on top of that, via environment stacking.
I suppose I could add the development tools into the normal project environment, maybe under [extras], though I still feel they shouldn’t be part of the environment proper. Anyway, I’ll stick with this approach for now, which also removes the need for running any startup code.
One thing you could do to avoid modifying LOAD_PATH is to build a separate environment for development purposes (much like it is customary to have a separate environment to add doc-building-time dependencies such as Documenter).
The process to build such an environment could be something like:
create a folder for it (e.g. named dev_env),
Pkg.activate this folder, and
Pkg.develop your package and Pkg.add other development-time dependencies in it.
In VS Code, you can then choose the environment you want to work in: either the regular package environment containing only runtime dependencies, or the environment defined by dev_env/Project.toml and containing extra development-time deps.
That would indeed also work. But the downside is you have to maintain two overlapping (with regards to included packages) environments. I.e., suppose you want to remove a package which you no longer use, you need to remember to remove it from both envs (though I guess keeping it in the dev env is not an issue).
Not really: the dependencies of your package are automatically pulled into the dev_env environment (as indirect dependencies) when you Pkg.dev your package into it. So that:
direct dependencies of your package are explicitly listed (only) in the “master” Project.toml
additional development-time dependencies are listed (only) in dev_env/Project.toml.
So no redundancy here. There is also no need for you to remember to keep these two environments in sync: when you add (or remove) a dependency in the master environment, Pkg will ask you to re-resolve the dev_env environment to reflect these changes.
Ah, my bad. I seem to have misinterpreted the documentation of ]?dev, from which I did not gather that this is quite similar to ]add. (Though this is explained more clearly elsewhere in the Pkg.jldocumentation, and in Add vs dev at a local path .)
Using dev is then a very neat and elegant solution!