**ERROR:** On worker 2:
ArgumentError: Package HelloWorld [cf8bea5c-a91a-11e8-2ba1-4f0c15a7916a] is required but does not seem to be installed:
- Run `Pkg.instantiate()` to install all recorded dependencies.

When do you call Pkg.instantiate()? After having activated the environment?

In order to refer to MyType across all processes, DummyModule.jl needs to be loaded on every process. Calling include("DummyModule.jl") loads it only on a single process. To load it on every process, use the @everywhere macro (starting Julia with julia -p 2 ):

Still, assuming that users would like to use the activated environment (and loaded packages) across workers seems like a reasonable default to me. Are there any technical/usability reasons why this is not the case?

If you activate the environment and restart julia, do you still have to activate it to import on all workers? Since you start julia with workers in a state where the environment is not fully set up, maybe code loading on the workers is affected. Once the environment has been set up, new workers started will perhaps have this same environment?

Yes, because Julia starts in the v1.0 environment by default. I also tried activating the environment first and then launching the worker processes with addprocs(), but I still get a ArgumentError: Package HelloWorld not found in current path: from Worker 2.

I seem to be getting the same issue on v1.0 but the Pkg.activate fix doesn’t work. As a test, I’m running…

using Distributed
addprocs(2)@everywhere push!(LOAD_PATH, “.”)@everywhere using Pkg@everywhere Pkg.activate(".")@everywhere using M

…where module M only contains the line println(“Loaded M on $(myid())”). This returns the error

LoadError: On worker 2: Failed to precompile M [top-level]

As with teored90’s issue, it works just fine in serial. When I attempt to add a package via @everywhere using (was testing with “Interpolations”) rather than a user defined module it also fails, only with a directory error instead of a precompile one (this also works in serial). The addprocs(2; exeflags="–project") fix mentioned by ksmcreynolds didn’t seem to have any effect. Has anyone seen / figured out a way around this problem? Thanks!

The problem AFAIU is that there’s no way to guarantee that the paths for deved packages are portable across machines (which can happen e.g. on a large cluster). Here’s @StefanKarpinski(link)

This requires some careful thinking about how best to do this. One possibility is to send a manifest from the master node to the workers and insist that the manifest be usable on all nodes. That’s fine for non-dev packages and even for dev packages with relative paths but dev packages with absolute paths may be a bit of an issue. We could rewrite dev paths to use a commit instead and then send that over; of course, it requires that the workers know about the tree hash that’s being used…