Activating test dependencies?

Is it possible to activate the extras/test dependencies of a project, e.g. for running tests manually/interactively (instead via Pkg.test())?


cd into the directory and start julia there with julia --project. Then in package mode do instantiate. Then include("runtest.jl") (or whatever).

Sure, that activates the project and it’s deps become available. But the packages in [extras], resp. referred to by test = ... in [targets] aren’t part of a normal project activation. At least I’ve never had them available by just activating/instantiating a project. Have I missed something?

No easy way:

I usually manually create the project file and activate it


Ah, thanks Mosè! I was wondering if there was an issue about it, but didn’t find it.

I guess for debugging complex packages, one would also want all optional deps (loaded via Requires.jl) of the package in question available … but that’s of course beyond the job of Pkg.

Oh silly me - the optional/Require deps should obviously be part of the test deps of the package already, so no problem there.

Post Julia 1.1 solution:


  1. Create a test/Project.toml
  2. in it all your test-time dependencies.
  3. Remove them and the other test time stuff from the main Project.toml


For testing ] test will work as before.

For manually activating:

  1. Activate the main environment
  2. Do push!(Base.LOAD_PATH, "./test"), (assuming currently directory is in basedir of project)
  3. You should now be able to using any package from either Project.toml

This feels like a gross hack to me.
There has been issues about creating nicer ways to activate stacked environments.
Maybe @StefanKarpinski or @kristoffer.carlsson have more thought in this direction


Yes, thoughts to make it better. Will happen at some point :slight_smile:


Is this approach stable now? I like it much better, but it had bitten me before:

For this to work, I think it is necessary for test/Manifest.toml to exist. To create it, do ]activate test and ]instantiate.

But then version resolution doesn’t seem to happen jointly. I’ve had more success with working in the test environment and doing ]dev ..

1 Like

A bit late to the party, but TestEnv.jl now exists and solves exactly this problem.


Yes, TestEnv.jl is great, thanks again to @oxinabox for creating it!

1 Like