Setting environment and instantiating packages in one step?

New to Julia
1

Hi,

Is it possible to use a single command to activate an environment and instantiate all of its packages?

It’s been a while since I played with rust, but I seem to remember that I could check out a repo, type cargo run (or cargo test) and have it install what I needed and run (or test) the project.

I haven’t found the equivalent in julia. julia --project=@. is close: it seems to activate the environment, but doesn’t seem to instantiate the packages?

My best guess so far is julia --project=@. -e"using Pkg; Pkg.instantiate()" src/main.jl, but -e and running a file seem to be mutually exclusive?

Is there an obvious option I’ve missed? This is not a big deal - it’s easy to write a shell script with a setup and a run option. I would just like to check that I’m making the most of Julia’s capabilities.

Thanks in advance!
Geoff

1 Like
2

I’m assuming these are your packages? I usually put a run.jl in the root folder that usually starts with:

using Pkg

Pkg.activate(".")

include("src/main.jl")

So to run my package I’m just executing julia run.jl in the project’s folder (rather than the src folder). If the package does something long running (like start a web server) Before the activate I’ll have something like:

if @isdefined(instance) && instance !== nothing
    Package.stop(instance)
    global instance = nothing
end

Where Package is the name of the module defined in src/main.jl. That way during development if I re-run run.jl it will stop the old code before the newer code is loaded and started.

3

Thanks!

The include trick makes it work.

Yes, these are our packages. We use a similar pattern, but with a shell script, which is now, thanks to your response:

#!/bin/bash
case $1 in
    run)
        julia --project=@. -e"using Pkg; Pkg.instantiate(); include(\"src/main.jl\")" -- -l debug
        ;;
    # other options
esac

So you can just type ./admin run and it should “just work”. What’s nice here is that the command-line options work!

Thanks again!
Geoff

4

This just works except for one corner case: if the user should happen to already have a copy of the General registry, which is outdated enough to completely miss one of the packages in the Manifest.

5

Thanks! Is there a solution for that case?

6

You can do a Pkg.Registry.update() before instantiate, but it’s a tradeoff with speed.

7

Oh, thanks!

Maybe a try-catch around the instantiate? But what I have hits the 80/20 rule, so I’m pretty happy with it.