julia.additionalArgs -e (...) REPL not recognised

Hi,

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
  • VS Code:
Version: 1.96.2 (user setup)
Commit: fabdb6a30b49f79a7aba0f2ad9df9b399473380f
Date: 2024-12-19T10:22:47.216Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.19045
  • VS Code Julia extension: v1.127.2

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.)

Looks like a bug to me. You should raise an issue on GitHub - julia-vscode/julia-vscode: Julia extension for Visual Studio Code.

Is this expected behaviour, or a bug?

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.

2 Likes

Thank you both for your replies!

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.

FWIW, we could make this work. You could also consider putting your code into startup.jl, which seems like a pretty appropriate place for it anyways.

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:

  1. create a folder for it (e.g. named dev_env),
  2. Pkg.activate this folder, and
  3. 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.

1 Like

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).

Such an approach (see also Understanding the startup.jl file -- is there a environment-specific version? - #2 by c42f) could indeed work. Presumably there is also a way to check which terminal is being used, and if is the VS Code one you could then load development-specific startup code.

Yet another solution, closest to what I originally had in mind, would be to make use of the -L flag in Julia to load a specified file:

  • Directory tree:
project/
├─ Project.toml        (contains e.g. StaticArrays)
├─ Manifest.toml
├─ dev_env/
│  ├─ Project.toml     (does not contain StaticArrays, but e.g. Cthulhu)
│  ├─ Manifest.toml
│  ├─ dev_startup.jl
├─ .vscode/
│  ├─ settings.json
...
  • dev_startup.jl:
push!(LOAD_PATH, @__DIR__)
  • settings.json:
{
    "julia.additionalArgs": [
        "-L",
        "${workspaceFolder}/dev_env/dev_startup.jl"
    ]
}

(In case you’re wondering: first the global startup.jl file is run, then dev_startup.jl and finally terminalserver.jl.)

This approach seems to work fine.

1 Like

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.


That’s a clever idea!

1 Like

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.jl documentation, and in Add vs dev at a local path .)

Using dev is then a very neat and elegant solution!