Compiling with package environments?

hi all,

after digging around with documentation, I still don’t quite understand how Julia handles project/environments.

So to describe what I am trying to do - I’ve created a new folder to house julia files related to the project, and I want it to use specific version of packages, separate from what the main environment is using.
I went to REPL, and run
“active Z:/project/Project1”

which activated the new env… I’ve added packages to it - it created a new (as documentation said) Manifest & Project toml files in the folder along with the jl files there.

But when I compile/run those jl files in VS Code, it ignores the .toml files in the folder, and just defaults to using the main environment.
meaning, I have ProjectA.jl in folder with Manifest.toml & Project.toml, with a bunch of
“using PackageABC” to kick off the script in ProjectA.jl, but it’s clearly going back to main environment to use packages there.

I cant quite figure out what I need to do to get it to use those .toml files. How do I get a script to run starting in a specific environment?

julia documentation gives this hint to just force entire environment - but it’s from command line:

Instead of using activate from within Julia you can specify the project on startup using the --project=<path> flag. For example, to run a script from the command line using the environment in the current directory you can run

$ julia --project=. myscript.jl

VSCode shows the current environment on the bottom half left line:


Perhaps VSCode is in another one.

oh lord… yeah… i closed VS code and restarted it, and the environment magically showed up…

is there a way to activate a specific environment from the script itself? Something akin to “active this env” before “using package xyz”?

I don’t know but for me VSCode remembers the environment for every project folder I open. Don’t know how it works or what to do, if it wouldn’t work like this.

Yes, I think that if Project.toml & Manifest.toml exist when you open the project in VS Code, then the environment will get activated automatically.

If it is not the case, you can click on the part of the status bar that shows the environment (what @oheil’s screenshot shows), and you’ll get a menu allowing to change the currently active environment.

Yes, this may not be the best way to do things for interactive development, but for scripts that are meant to be run non-interactively, something like this can be very useful:

using Pkg               # assuming Project.toml can be found in the same
Pkg.activate(@__DIR__)  # directory as the script where these lines appear

# Now you can safely use any package listed in the dependencies
using XYZ
1 Like